Member ist die Lead-Tabelle für das Vertragsverhältnis Mitglied↔Verein — nicht für den Menschen (das ist die Person). Verknüpfung M:N über LinkMemberPerson mit relation_type: eine Familienmitgliedschaft kann mehrere Personen haben, eine Person mehrere Mitgliedschaften.
| Feld | Bedeutung |
|---|---|
display_name |
Bezeichnung der Mitgliedschaft (Fallback: Hauptkontakt-Name oder „Mitglied {nr}") |
member_number |
optional, unique pro Club; Auto-Vergabe: max(bestehende int-Nummern)+1, mindestens 1000. Alphanumerische Nummern (M-2026-001) bleiben unangetastet |
member_single |
Einzelperson vs. Kollektiv — wird automatisch abgeleitet aus der Anzahl verlinkter Personen |
status |
nur aktiv/passiv |
exited / exit_date |
Austritt ist unabhängig vom Status. Ein Austrittsdatum setzen impliziert exited=True. Der 3-Wert-Import „aktiv/passiv/ausgetreten" wird zu status=passiv + exited=True aufgeteilt |
additional_person_data |
JSON-Parkplatz für Personen-Spalten aus Mehrpersonen-Excels (Legacy — seit v0.16.17 landet hier fast nichts mehr) |
relation_type-Werte: contact (Label „Mitglied", Standard bei Einzelmitgliedschaft), primary_contact, secondary_contact, billing, legal_guardian, child, emergency_contact, participant, player, custom (+ Freitext).
/clucore/mitglieder/)Vue3-„CluhuTable"-Power-Widget, gefüttert von member_list in apps/organization/api.py.
sort=address__postal_code)filter[feld]=… typenspezifisch (text/exact/boolean/number/date/select), auch für Custom-Felder und Adress-Komponenten. member_number filtert exakt — damit „2" nicht auch „12" trifftLeadtableView), speichern Spalten/Sortierung/Ergebniszeile; eines kann Default sein. Zusätzlich Session-Persistenz des aktuellen Zustands?filter[member_number]=… / ?filter[person_number]=…) — jede Liste übernimmt URL-Filter beim Laden. ⚠️ Der Filter wird in der Session gemerkt und bleibt bis zum manuellen Entfernen?manual=1 überspringt ihnmember_reset_all): verlangt exakte Texteingabe. Löscht Mitglieder, Cell-Values, Import-Batches, importierte Personen ohne Login, verwaiste Adressen/Telefone und leere Feld-Definitionen. Manuell erfasste und Login-Personen bleiben/clucore/mitglieder/zuordnung/)Siehe Mehrpersonen-Mitgliedschaft für den Canvas und Design-Entscheidungen für die Feld-Eigentümerschafts-Geschichte. Kurzfassung:
?view=list — „Spalten-Eigenschaft" (Simpel-Modus): Regel „Spalte → Person/Feld" ohne Canvas?view=firmen — Firmen-Canvas (braucht Addon „Firmen Mitglieder")Der Apply-Motor befüllt nur leere Ziele und konsumiert den Member-Wert (Verschieben, nicht Kopieren — „eine Wahrheit"). Danach projiziert die Mitglieder-Spalte das Personen-Feld; Edits schreiben durch (Write-Through). Regeln liegen in PersonFieldMapping (persistent, Import-Sync via sync_import_mappings, verwaiste Regeln bleiben sichtbar statt still zu verschwinden).
EAV-System: CustomColumnDefinition (pro Club + Ziel-Objekt, Datentypen: text, textarea, checkbox, dropdown, multiselect, date_picker, number, asset, email/phone/address = strukturierte Kontakt-Typen, entity_link = read-only Fremdfeld) → CustomColumnCellValue (polymorph, typisierte Slots). Validierungsregeln in CustomColumnAttribute, Dropdown-Optionen mit Farbe/Icon.
Strukturierte Kontaktfelder (v0.16.53): eine zweite E-Mail-/Telefon-/Adress-Spalte wird als Custom-Feld definiert, die Werte liegen aber in den echten Entitäten (EmailAddress/PhoneNumber/Address), nicht als Text — dadurch bleiben sie validier- und verknüpfbar.
Feldtyp-Konvertierung bestehender Werte: /api/columns/fields/<id>/convert/ mit Dry-Run-Prüfung aller Werte vor der Umstellung.