Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(einsatzdaten): the address model cannot hold a house number, PLZ or Ort

Closed
  • Is something wrong?
#401 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, sqlite
Domain
backend, database

Research direction

Start with Incident.cs, Formatting.Address, and the existing migration chain in Sqlite/Migrations.cs (currently v21); then trace the fields through IncidentDataDialogView.axaml, IncidentHeaderSection.cs, and the sync snapshot. The issue leaves open whether District remains distinct from Place, so settle that design question before changing the model. Done means optional address fields are migrated and carried through the form, formatting, PDF header, and sync.

Written by the indexing model from the issue text.

Description

enhancement

From a portability review of main (ecb341b).

The gap

An incident's location is two free-text fields and nothing else:

// src/LageBuch.Domain/Incident.cs
public string? Street   { get; private set; }   // :40
public string? District { get; private set; }   // :42

Columns incident_meta.street and incident_meta.district; Formatting.Address joins them with ", "; the placeholders are z. B. Hauptstr. 12 and z. B. Puch (IncidentDataDialogView.axaml:31,34). There is no house-number field (it goes in Street by convention), no PLZ, no Ort, no country.

Why it is a limit even in Bavaria

For a Feuerwehr documenting incidents inside its own Gemeinde this is exactly right and adding fields would be noise. It stops working in two cases that are not unusual:

  • Überörtliche Hilfe. The Ort is the discriminating field and there is nowhere to put it. Today it goes in District, which then means something different from one incident to the next.
  • A Landkreis-level ELW. Same problem, permanently.

The PDF header (IncidentHeaderSection.cs:53) and the Einsatzbericht that reaches the Kreisbrandinspektion inherit the ambiguity.

Outside Germany it is a harder stop: UK postcodes and US city/state/ZIP have nowhere to go at all.

Proposal

Add HouseNumber, PostalCode and Place to incident_meta, keep Street and District, and keep every field optional so the current one-Gemeinde workflow stays a two-field form. Formatting.Address grows a canonical join that drops the empties.

.fwincident has a real migration chain (Sqlite/Migrations.cs, currently at v21) so this is a routine additive migration — no data loss, old files open with the new fields null.

Fields follow through to IncidentDataDialogView, IncidentHeaderSection, and the sync snapshot.

Open question

Whether District (Ortsteil) survives as its own field once Place exists, or whether the two collapse. I lean towards keeping both — an Ortsteil is genuinely how a rural incident gets located, and it is not a city district.

Dominant language
C#
Stars
1
Forks
3
Avg merge
4h 15m
Merged PRs (30d)
181

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeForFire/lagebuch

All issues in CodeForFire/lagebuch

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.