Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#401 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, sqlite
Área
backend, database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
1
Forks
3
Merge medio
4 h 49 min
PR fusionados (30 d)
177

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CodeForFire/lagebuch

Todos los issues de CodeForFire/lagebuch

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.