[FEATURE]: Concept how custom fields are handled

carla commented

2025-09-11 13:16:34 +02:00

Owner

Description

As a user I want to add custom fields, in order to filter for these fields and get members with specific properties.
Example: Different interests, or for sport associations: "Sparte"

Acceptance criteria

A clear concept is documented how to handle custo fields
We know where in the UI custom fields can be added/edited/deleted
We know what happens after deleting a custom field
We know the difference between tags and custom fields

Notes

Custom fields especially important for communication:
Flow: Filter for a field - get email addresses from the results - communicate with the specific members

## Description As a user I want to add custom fields, in order to filter for these fields and get members with specific properties. Example: Different interests, or for sport associations: "Sparte" ## Acceptance criteria - [ ] A clear concept is documented how to handle custo fields - [ ] We know where in the UI custom fields can be added/edited/deleted - [ ] We know what happens after deleting a custom field - [ ] We know the difference between tags and custom fields ## Notes Custom fields especially important for communication: Flow: Filter for a field - get email addresses from the results - communicate with the specific members

carla added this to the I can add custom fields milestone 2025-09-11 13:16:34 +02:00

simon commented

2025-10-02 12:35:09 +02:00

Owner

would propose to do this in pair "programming" :)

simon added this to the Sprint 7 - 02.10 - 23.10. project 2025-10-02 12:35:15 +02:00

simon added the

high priority

M

labels 2025-10-02 12:35:27 +02:00

simon commented

2025-10-16 16:00:58 +02:00

Owner

gern – hier ist die kompakte Zusammenfassung für euer internes Abstimmungspapier:

Grundlegender Lösungsansatz

Custom Fields werden in der Anwendung auf Basis der bereits existierenden Strukturen Membership.Property und Membership.PropertyType weiterentwickelt. Jede Organisation kann damit eigene zusätzliche Felder definieren, die typisiert, validiert und konfigurierbar sind. Diese Felder bilden die Grundlage, um Mitgliederinformationen flexibel zu erweitern, zu filtern und gezielt für Kommunikation oder Auswertungen zu nutzen.

Die Umsetzung folgt einem schrittweisen Vorgehen: Zunächst wird die fachliche Semantik und Validierung im Domain-Layer gefestigt (Soft-Delete, Typvalidierung, Enum-Verhalten). Danach folgen UI- und Filterfunktionen, Self-Service-Integration und ergänzende Governance-Themen wie Quotas, Audit oder Export. So bleibt das System stabil, aber anpassbar für unterschiedliche Organisationsanforderungen.

Getroffene Designentscheidungen

Technische Basis: bestehende Module Membership.Property und Membership.PropertyType bleiben Kern der Implementierung.
Identität: Property-Identifier (Slug/Key) sind nach Anlage unveränderlich.
Soft-Delete: Typen und Optionen werden soft gelöscht bzw. archiviert; bestehende Werte bleiben erhalten.
Hard-Delete: nur möglich, wenn keine abhängigen Werte existieren.
Typisierung: unterstützt :string, :integer, :boolean, :date, :email (Enum-Varianten ergänzt).
Validierung: Werte werden domänenseitig entsprechend des Typs geprüft.
Sektionen: in v1 feste Sektion „Zusatzfelder“, spätere freie Zuweisung möglich.
Self-Service: Sichtbarkeits-Flags vorgesehen, Umsetzung in späterem Schritt.
RBAC: aktuelle Rechte (Mitglieder bearbeiten / Einstellungen verwalten) werden genutzt; spätere Gruppenrechte integrierbar.
Quotas: technische Limits per Konstante/ENV konfigurierbar.
Audit, Export, Spezialtypen: explizit als spätere Erweiterungen vorgesehen.

Gliederung der Issues

Issue	Thema / Zweck
CF-01	Custom Properties – Basissemantik & Validierung: Festlegung der Domainlogik (Identität, Soft-/Hard-Delete, Typprüfung, Enum-Verhalten).
CF-02	Admin-UI für Custom Fields: Oberfläche zum Anlegen, Bearbeiten, Sortieren und Soft-Löschen von Properties.
CF-03	Mitglied-Detailansicht: Zusatzfelder: Anzeige und Bearbeitung der definierten Custom Fields im Mitglieder-Formular.
CF-04	Filter & Spalten: Nutzung der Custom Fields in der Mitgliederliste zum Filtern, Sortieren und optionalen Einblenden von Spalten.
CF-05	Self-Service-Integration: Anzeige/Bearbeitung eigener Zusatzfelder durch Mitglieder entsprechend der Sichtbarkeits-Flags.
CF-06	Soft-Delete-Semantik & Hard-Delete-Guard: Sicheres Entfernen und Wiederherstellen von Feldern inkl. Schutz vor Datenverlust.
CF-08	Quotas & Systemhinweise: Begrenzung der Anzahl aktiver, filterbarer und sichtbarer Felder; Anzeigen von Warnungen.
CF-09	API/CSV-Export-Integration: Bereitstellung der Custom-Field-Daten in Exporten und API-Antworten (z. B. `custom_fields.slug`).

Spätere Epics (Backlog)

Audit & Revision: Nachvollziehbarkeit von Änderungen an Definitionen und Werten.
Spezial-Validatoren & Formatierungen: Validierungen für URL, IBAN, Currency, Telefon etc.
Export-Wizard: Benutzerfreundliche Auswahl und Speicherung von Exportspalten.
Bedingte Felder / Regeln: Sicht- oder Pflichtabhängigkeiten zwischen Custom Fields.
Mehrfach-Adressen (eigenes Epic): separate, wiederholbare Struktur für zusätzliche Adressobjekte.

Damit habt ihr eine klare Übersicht über Ziel, Entscheidungen und die geplante Aufteilung für die interne Abstimmung.

Tags vs. Custom Fields (Arbeitsdefinition v1)

Tags: freie, mehrwertige Labels für schnelle Segmentierung (“Newsletter”, “Ehrenamt”). Kein Datentyp, nur Text; ideal für ad-hoc Gruppierung.

Custom Fields: typisierte Felder mit Validierung, Berechtigungen & Sichtbarkeit; dienen auch als Filter- und Spaltenquelle.

gern – hier ist die kompakte Zusammenfassung für euer internes Abstimmungspapier: --- ## Grundlegender Lösungsansatz Custom Fields werden in der Anwendung auf Basis der bereits existierenden Strukturen `Membership.Property` und `Membership.PropertyType` weiterentwickelt. Jede Organisation kann damit eigene zusätzliche Felder definieren, die typisiert, validiert und konfigurierbar sind. Diese Felder bilden die Grundlage, um Mitgliederinformationen flexibel zu erweitern, zu filtern und gezielt für Kommunikation oder Auswertungen zu nutzen. Die Umsetzung folgt einem schrittweisen Vorgehen: Zunächst wird die fachliche Semantik und Validierung im Domain-Layer gefestigt (Soft-Delete, Typvalidierung, Enum-Verhalten). Danach folgen UI- und Filterfunktionen, Self-Service-Integration und ergänzende Governance-Themen wie Quotas, Audit oder Export. So bleibt das System stabil, aber anpassbar für unterschiedliche Organisationsanforderungen. --- ## Getroffene Designentscheidungen * **Technische Basis:** bestehende Module `Membership.Property` und `Membership.PropertyType` bleiben Kern der Implementierung. * **Identität:** Property-Identifier (Slug/Key) sind nach Anlage unveränderlich. * **Soft-Delete:** Typen und Optionen werden soft gelöscht bzw. archiviert; bestehende Werte bleiben erhalten. * **Hard-Delete:** nur möglich, wenn keine abhängigen Werte existieren. * **Typisierung:** unterstützt `:string, :integer, :boolean, :date, :email` (Enum-Varianten ergänzt). * **Validierung:** Werte werden domänenseitig entsprechend des Typs geprüft. * **Sektionen:** in v1 feste Sektion *„Zusatzfelder“*, spätere freie Zuweisung möglich. * **Self-Service:** Sichtbarkeits-Flags vorgesehen, Umsetzung in späterem Schritt. * **RBAC:** aktuelle Rechte (Mitglieder bearbeiten / Einstellungen verwalten) werden genutzt; spätere Gruppenrechte integrierbar. * **Quotas:** technische Limits per Konstante/ENV konfigurierbar. * **Audit, Export, Spezialtypen:** explizit als spätere Erweiterungen vorgesehen. --- ## Gliederung der Issues | Issue | Thema / Zweck | | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------ | | **CF-01** | **Custom Properties – Basissemantik & Validierung**: Festlegung der Domainlogik (Identität, Soft-/Hard-Delete, Typprüfung, Enum-Verhalten). | | **CF-02** | **Admin-UI für Custom Fields**: Oberfläche zum Anlegen, Bearbeiten, Sortieren und Soft-Löschen von Properties. | | **CF-03** | **Mitglied-Detailansicht: Zusatzfelder**: Anzeige und Bearbeitung der definierten Custom Fields im Mitglieder-Formular. | | **CF-04** | **Filter & Spalten**: Nutzung der Custom Fields in der Mitgliederliste zum Filtern, Sortieren und optionalen Einblenden von Spalten. | | **CF-05** | **Self-Service-Integration**: Anzeige/Bearbeitung eigener Zusatzfelder durch Mitglieder entsprechend der Sichtbarkeits-Flags. | | **CF-06** | **Soft-Delete-Semantik & Hard-Delete-Guard**: Sicheres Entfernen und Wiederherstellen von Feldern inkl. Schutz vor Datenverlust. | | **CF-08** | **Quotas & Systemhinweise**: Begrenzung der Anzahl aktiver, filterbarer und sichtbarer Felder; Anzeigen von Warnungen. | | **CF-09** | **API/CSV-Export-Integration**: Bereitstellung der Custom-Field-Daten in Exporten und API-Antworten (z. B. `custom_fields.slug`). | ### Spätere Epics (Backlog) * **Audit & Revision:** Nachvollziehbarkeit von Änderungen an Definitionen und Werten. * **Spezial-Validatoren & Formatierungen:** Validierungen für URL, IBAN, Currency, Telefon etc. * **Export-Wizard:** Benutzerfreundliche Auswahl und Speicherung von Exportspalten. * **Bedingte Felder / Regeln:** Sicht- oder Pflichtabhängigkeiten zwischen Custom Fields. * **Mehrfach-Adressen (eigenes Epic):** separate, wiederholbare Struktur für zusätzliche Adressobjekte. --- Damit habt ihr eine klare Übersicht über Ziel, Entscheidungen und die geplante Aufteilung für die interne Abstimmung. ## Tags vs. Custom Fields (Arbeitsdefinition v1) **Tags**: freie, mehrwertige Labels für schnelle Segmentierung (“Newsletter”, “Ehrenamt”). Kein Datentyp, nur Text; ideal für ad-hoc Gruppierung. **Custom Fields**: typisierte Felder mit Validierung, Berechtigungen & Sichtbarkeit; dienen auch als Filter- und Spaltenquelle.

simon self-assigned this 2025-10-16 16:04:29 +02:00

simon modified the project from Sprint 7 - 02.10 - 23.10. to Sprint 8 - 23.10 - 20.11

2025-10-23 13:14:24 +02:00

moritz closed this issue

2025-11-11 15:49:37 +01:00

Rows
Columns

[FEATURE]: Concept how custom fields are handled #157

Description

Acceptance criteria

Notes

Grundlegender Lösungsansatz

Getroffene Designentscheidungen

Gliederung der Issues

Spätere Epics (Backlog)

Tags vs. Custom Fields (Arbeitsdefinition v1)