@gunnar ok, da hänge ich mich mal dran ...
ausgehend von der Unterscheidung zwischen
Datenbankfeldern in den Stammdaten (Felder für die Personendatebank - verschiedene Abschnitt ) DatenbankGruppenfelder ( Datenbankfelder in den Stammdaten Kategorie Gruppe) GruppenMitgliedsfelder (ich nenn das mal so - Felder in einer bestimmten Gruppe - "Weitere Felder hinzufügen")In Verbindung mit der Diskussion in https://forum.church.tools/topic/7227/gruppenmitgliedschaft-ist-personenbezogenes-datum-wie-kann-ich-level-zuordnen/30 wäre es super, wenn möglichst zeitnah eine substantielle Verbesserung bei "Weitere Felder hinzufügen" in Gruppen kommen könnte.
Das ganze ist getriggert durch den Hinweis: d6b6e4e5-4e9a-45b2-87d0-90f7cc625015-image.png
Wenn die GruppenMitgliedsfelder ähnlich mächtig wären wie die Datenbankfelder, dann könnte man (danke für den Hinweis @Andy) auch eher komplexe Informationsstrukturen schön partitionieren.
Das ist das Modell (Entwurf) in welches wir importieren wollen. Die Aufteilung zwischen Personentabelle und Merkmalsgruppen ist von den technischen Möglichkeiten in CT getrieben (z.B. davon dass man nach Datenbankfeldern nicht filtern kann), leider nicht von unseren Anforderungen. Wir hätten gerne mehre Datumsfelder in MG Davip_Ereignisse
01_mediator--real.png
konkrete AnforderungenIm Grunde sollte es also für GruppenMitgliedsfelder die gleichen Möglichkeiten geben wie bei DB-Felder (Ich priorisiere mal nach A, B, C)
A damit wir die Daten jetzt schon richtig importieren können B ist ähnlich dringend, aber aufwand scheint mir höher C würde man aus Konsistenzgründen erwarten brauchen wir aber nicht so dringend, weil unsere Ausgangsdaten den Fall nicht mitbringen. Datentypendie gleichen Datentypen wie bei den DB-Feldern
f3a15179-5dd2-45aa-bb41-936bced0be34-image.png vs. 9cf7f522-8f6f-475d-8421-dbe327decdf4-image.png
Insbesondere die Typen :
Prio-A: Datumsfeld - Wir möchten diverse Datumsfelder bei manchen Personen erfassen.
Die Gruppenfelder sind aber im Datumsfilter nicht zugänglich ... und es gibt keine Datumsfel bei den Gruppenfeldern,
Prio-B: Auswahlfeld/Mehrfachauswahl ( mit Referenz auf einen Datenbanktabelle). Wir haben mehrere Felder mit derselben Auswahl, da wäre es super, wenn das gegen eine gemeinsame Definition laufen könne. Ausserdem kann man die Beschreibung der Auswahl nicht mehr ändern, ohne die bisherigen Daten zu verlieren. - Kurzum das Auswahlfeld/Mehrfachauswahl in den Gruppenfeldern ist nicht gut gelungen ....
Ich setze es auf B weil es vermutlich deutlich aufwändiger ist. eigentlich ist es Prio A.
Wenn es denn kommt, müssten es dann ohne Konvertierung in der Datenbank einführbar sein.
Prio B: Mehrzeiliges Textfeld (Kommentarfeld)
weitere AnforderungenPrio-A: im Suchfilter für Text- bzw. Zahlenfelder auch die Relation "größer /größer gleich / kleiner / kleinergleich" zulassen. Damit könnte man zumindest mit Textfeldern ein Datumsfeld faken.
Prio-B: im Suchfilter für Textfelder auch reguläre Ausdrücke zulassen. Ich setze das auf B weil reguläre Ausdrücke nicht wirklich jedem zugägnlich sind. Aber ein Admin hätte damit die Möglichkeit ein globales Filter zu setzen.
Prio B: gleiche Handhabung wie bei den DB-Feldern (insbesondere Sortierung in der Kopfzeile der MItgliedsliste, so dass man bestimmen kann, wo das Feld erscheint).
Anlage der Felder in einem eigenen Dialog, nicht in der Kopfzeile der Mitgliedertabelle. Dabei wählen, ob es in der Mitgliedsliste erscheint.
Prio C: Möglichkeit einer Vorlage beim Export) wenn man aus der Gruppe exportiert). Immerhin kommen gerade alle Felder, daher kann man mit Prio-C leben.
Prio B: Gruppenfelder auch in der Personenliste-Export-Vorlage anwendbar machen, (also wenn man einen Personenliste exportiert).
man könnte damit leben, dass die Gruppenfelder Systemweit eindeutige Namen haben müssen. Das ist schon jetzt sehr sinnvoll, weil man über Gruppenfelder filtern kann, ohne eine Gruppe auszuwählen.
60b38010-19ee-4097-93d3-ee0047725bce-image.png
Prio B: Definition sollte eher bei den Stammdatenn erfolgen, da sie eigentlich von einem Admin eingerichtet werden sollten. die Definition über das 364cc8d9-3033-4d00-91b9-81962f52cc7c-image.png finde ich nicht sehr glücklich.
Prio C: Im Grunde müsste man GruppenMitgliedsfelder auch beim Gruppentyp definieren können.
Vielen Dank fürs Lesen bis hierher. Ich würde mich über Kommentare vor allem von den CT-Entwicklern freuen.