[FEATURE] Address model rework incl. Country #550

New issue

Open

opened 2026-06-30 16:08:53 +02:00 by simon · 0 comments

simon commented

2026-06-30 16:08:53 +02:00

Owner

Description

Rework the member address at the data-model level, including proper Country support. Today the address is four flat columns (country, city, street, house_number, postal_code) with limited structure. This is a wide-reaching change (migration + every touchpoint) and requires its own best-practice research first (international address modelling). It is decoupled from the overview redesign: the table already presents a composite address cell purely at the display layer, so this can proceed on its own schedule.

Scope — in

Best-practice research on international address modelling (structured vs. free-form, Country handling, postal-code validation per country, libraries/standards) — recorded before implementation.
DB schema for a structured address incl. Country; migration with backfill from the current fields (no data loss).
Update all touchpoints: member create/edit form, import, export (CSV/PDF), validation, and search / filter / sort over address parts.
Keep city / postal code findable (search + filter) throughout.

Scope — out

Overview layout/filter/views work (parts 1–3).

Acceptance criteria

International-address best-practice research completed and recorded (decision on structure + Country handling).
Address modelled with Country; migration backfills existing data with no loss.
All touchpoints updated and consistent: form, import, export, validation, search, filter, sort.
City / postal code remain searchable and filterable.
CI green; no regression in member create/edit/import/export.

Dependencies

Independent of the table redesign; can run after #547 (display already decoupled).

References

Analysis doc issue-512-member-overview-redesign.md — §9 (D4, D25c), §10 (split item 4).
Parent: #512.

## Description Rework the member **address at the data-model level**, including proper **Country** support. Today the address is four flat columns (`country`, `city`, `street`, `house_number`, `postal_code`) with limited structure. This is a wide-reaching change (migration + every touchpoint) and **requires its own best-practice research first** (international address modelling). It is **decoupled** from the overview redesign: the table already presents a composite address cell purely at the display layer, so this can proceed on its own schedule. ## Scope — in - **Best-practice research** on international address modelling (structured vs. free-form, Country handling, postal-code validation per country, libraries/standards) — recorded before implementation. - DB schema for a **structured address incl. Country**; **migration** with backfill from the current fields (no data loss). - Update **all touchpoints**: member create/edit form, **import**, **export** (CSV/PDF), **validation**, and **search / filter / sort** over address parts. - Keep **city / postal code findable** (search + filter) throughout. ## Scope — out - Overview layout/filter/views work (parts 1–3). ## Acceptance criteria - [ ] International-address **best-practice research completed and recorded** (decision on structure + Country handling). - [ ] Address **modelled with Country**; migration backfills existing data with **no loss**. - [ ] **All touchpoints updated and consistent**: form, import, export, validation, search, filter, sort. - [ ] City / postal code remain searchable and filterable. - [ ] CI green; no regression in member create/edit/import/export. ## Dependencies - **Independent** of the table redesign; can run after #547 (display already decoupled). ## References - Analysis doc `issue-512-member-overview-redesign.md` — §9 (D4, D25c), §10 (split item 4). - Parent: #512.