Person ist die Lead-Tabelle für die Personen-Identität (Name, Geburtsdatum, Login) — im Gegensatz zum Member, das nur das Vertragsverhältnis trägt. Warum getrennt: Vorname/Adresse/Telefon sind personenbezogen, nicht mitgliedschaftsspezifisch (Person-Lead-Architektur, v0.14.60).
| Feld | Bedeutung |
|---|---|
display_name |
abgeleitetes Label: automatisch aus „Vorname Nachname" gepflegt (in save()). Nur mit display_name_override bleibt ein manueller Wert (Spitzname/Mononym) stehen. Fallback-Kette: Name → E-Mail-Local-Part |
person_number |
Anzeige-Nummer pro Verein, auto ab 0, UI-Format 5-stellig. 00000 = die zuerst angelegte Person (bei neuen Vereinen der Owner). Nicht editierbar. Auto-Vergabe mit Retry gegen Race-Conditions |
user |
OneToOne zu Django-User, NULL = Person ohne Login |
source |
import / manual / addon_wizard — steuert das Herkunfts-Tag in der Liste und was member_reset_all löschen darf |
Adresse, Telefon und E-Mail sind eigene Entitäten mit Links, keine Textfelder:
Address — M:N via LinkAddressPerson: eine Familienadresse ist ein Datensatz mit n Links (echtes Sharing statt String-Kopien)PhoneNumber — M:N via LinkPhoneNumberPerson (Familien-Festnetz teilbar). CH-Klassifikation: 075–079 = mobil (persönlich), Rest = Festnetz (teilbar) — steuert Sharing-DefaultsEmailAddress — bewusst 1:N (jede E-Mail gehört genau einer Person). Eine E-Mail nur EINMAL pro Verein, case-insensitiv erzwungen per DB-Constraint (club, Lower(email)). Grund: E-Mail = Login-Identität. save() normalisiert (trim + lowercase)Seit v0.18.5 gilt: Die Personen-E-Mail ist die einzige Wahrheit. Der Django-User spiegelt sie nur. Bei E-Mail-Änderung einer Login-Person wird User.username/email mitgezogen (mit blockierendem Bestätigungs-Dialog + Passwort-Reset-Mail an die neue Adresse).
Es gibt keine member-owned Kontakte und keine automatische Vererbung (Rückbau v0.16.77) — Teilen ist immer explizite Verdrahtung. Details: Design-Entscheidungen.
/clucore/personen/)Gleiche CluhuTable wie die Mitgliederliste, plus:
has_login-Filter; Login-Personen ohne EmailAddress zeigen die Login-Mail als E-Mail-Wert/clucore/rollen/)Role/LinkRole/RoleContext: fachliche Vereinsrollen, polymorph zuweisbar (Person/Firma) mit optionalem Kontext (z. B. „Trainer" im Kontext Gruppe X). Rollennamen dürfen keine Kommas/Klammern enthalten — das ist Anzeige-Syntax des Herkunftsmodells.
Hinweis: „Vereins-Rollen" war früher ein eigenes Addon (vereins-rollen), wurde aber dem Bereich Personen zugeschlagen. Rollen an Mitgliedschaften wurden abgeschafft (v0.16.95) — LinkRole mit object_type='member' ist serverseitig geblockt.
/clucore/personen/duplikate/)Namensbasierte Paar-Erkennung (first+last oder display_name, case-insensitiv). Merge biegt alle Links (Member, Company, Group, Role) auf die behaltene Person um.
⚠️ Läuft O(n²) bei jedem GET der Seite — bei >1000 Personen pro Verein braucht es eine Optimierung.
person_delete_all verlangt die exakte Texteingabe „ALLES LÖSCHEN". Login-Personen werden immer geschont — sonst sperrt sich der Admin selbst aus (die Tenant-Middleware prüft user.person.club_id; AuthRoleAssignment hat CASCADE auf Person).