User Interface "Weitere Felder hinzufügen" in Gruppen
-
Hallo liebe User-Interface Verantwortlichen bei Personen/Gruppen!
Es gibt die wunderschöne Möglichkeit, weitere Felder in Gruppen hinzuzufügen. Leider benötig das "+" Icon für diese Funktion eine ganze Spalte in der Gruppenansicht, in der dann nichts steht.
Wenn man einige Spalten zusätzlich angelegt hat, dann ist jeder Pixel in der Breite der Tabelle wertvoll und sollte nicht so verschwendet werden!Vorschlag/Wunsch das "+" Icon für "Weitere Felder hinzufügen" nach rechts in den Header der Spalte mit den Icons "Bearbeiten" und "Löschen" schieben - pretty please!
Mit anderen Worten von links neben "Dabei seit" nach rechts und dann die leere Spalte entfernen.
PS: Eigentlich sollte die Funktion bzw. der Dialog der sich öffnet Weiteres Feld hinzufügen heißen, zumindest mir ist es noch nie gelungen, Felder (plural) in einem Schritt=Dialog hinzuzufügen. Nur nice-to-have, zumindest ich konnte den falschen Plural bisher ignorieren:
-
@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:
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
konkrete Anforderungen
Im 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önnenB
ist ähnlich dringend, aber aufwand scheint mir höherC
würde man aus Konsistenzgründen erwarten brauchen wir aber nicht so dringend, weil unsere Ausgangsdaten den Fall nicht mitbringen.
Datentypen
-
die gleichen Datentypen wie bei den DB-Feldern
vs.
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 Anforderungen
-
Prio-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.
-
Prio B: Definition sollte eher bei den Stammdatenn erfolgen, da sie eigentlich von einem Admin eingerichtet werden sollten. die Definition über das 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.
-
@bwl21 sagte in User Interface "Weitere Felder hinzufügen" in Gruppen:
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,Hi, ich war mal ein paar Tage offline ... deswegen erst jetzt der Hinweis, den auch andere hätten geben können:
Jede Gruppenzugehörigkeit ist ein Datumsfeld, das nennt sich "Dabei seit".Beispiel: Also Merkmal "Erweitertes Führungszeugnis" für Kindermitarbeiter mit "Dabei seit" als Datum des letzten vorgelegten Zeugnis.
Gleiches geht mit Erstkommunion oder anderen Terminen. Weitere Gruppenfelder des Merkmals könnte dann "Bibelvers" sein.Hilft das beim Prio A Thema
-
@gunnar ja, das hilft bei Merkmalen, wo es genau ein Datum gibt. Nun möchte ich vermeiden, dass wir zu viele Merkmalsgruppen bekommen. Das ist etwas unhandlich bei der Bearbeitung einer Person, zumal man die Gruppentypen nicht zusammenklappen kann.
Wir haben uns daher entschlossen, die "exotischen" Datumsangaben als Textfeld abzulegen und von den wenigen Bearbeitern zu erwarten, dass sie diese im Format YYYY-MM-TT eingeben.
Bei Führungszeugnis und Präventsionsschulung werden wir genau deinen Vorschlag umsetzen.
Zur Information falls es jemand interessiert:
hier der geplante Stand unserer Merkmalsgruppen:
Die Aufteilung ist getrieben durch
- Sachlichen Zusamenhang
- Bedienbarkeit in CT
zum Vorgehen:
-
Ich haben eine Beschreibung der Abbildung (mediator) von DaviP-W auf CT erstellt (als PHP-Array). Dieses Array beschreibt für jedes Davip-Feld:
- Die Merkmalsgruppe
- Dei Feldbenennung
- Die Datenkonvertierung, auch das Berechnen des CT-Feldes als Kombination merhrere DaviP-Felder
- Das mapping der Auswahlen
-
aus dieser Datei kann wird die Grafik generiert, aber auch die Gruppen und Felder in CT per API angelegt
-
Damit kann ich auch den Import-Vorgang simulieren und die Datenqualität steigern.
-
Moin ich möchte nur kurz eine Info hier teilen, falls das noch nicht bekannt ist: Wir arbeiten gerade daran ein eigenes Gruppen Modul zu bauen. Das wir von der Pieke auf neu programmiert. Dabei werden UX/UI neu gedacht. Euer Feedback hier ist sehr wertvoll für diesen Prozesse.
Doch einen Zahn muss ich leider ziehen, wir werden wohl im alten Modul keine großen Änderungen dieser Art mehr einbauen. Diesen Aufwand stecken wir lieber in das neue Modul
Siehe https://blog.church.tools/blog/feature-ankundigungen-2021/