DB-Feld-Kategorie
-
Hallo,
ist es möglich eine eigene DB-Feld-Kategorie anzulegen?
MFG Patrick
-
Das ist momentan nicht möglich. Was ist denn die Idee dabei?
-
Besser gesagt stehen wir vor der Herausforderung, dass wir unseren Royal Ranger Stamm mit in Churchtools verwalten möchten.
Soviel ich weiß ist es aktuell nicht möglich Gruppenfelder an Kindergruppen zu vererben, zu exportieren und sie werden auch nicht im Personenprofil angezeigt.
Jetzt war die Idee die benötigten Felder als Standartfelder zu erstellen und in einer eignen Feldgruppe zu Bündel.
MFG Patrick
-
Mmh, leider verstehe ich nicht ganz was Du meinst. Magst Du es an einem Beispiel näher beschreiben?
Exportieren kannst Du mittlerweile die erweiterten Felder auch. Es gibt ein Exporter-Link in der Gruppen-Detailansicht.
-
@jmrauen Ah, jetzt erst entdeckt:
(CDB) Exportmöglichkeit für Gruppendetail-Listen inkl. der selbst definerten Felder.
Sehr cool!
-
Hallo,
im Vorgänger System hatten wir ca 30 Zusatzfelder (Allergien, Impfungen usw). die wir im Benutzerprofil verwaltet haben die es so nicht in Churchtools gibt.
Ich habe jetzt die Stammstruktur als Gruppe mit Untergruppen und Unteruntergruppen angelegt.
Hauptstamm
-Pfadranger
--TeamPR J
--TeamPR M
-Pfadfinder
--Team PF1
--Team PF2
--Team PF3
-Kundschafter
--Team KD1
--Team KD2
--Team KDx
-Starter
--Starterteam 1Ziel ist es am Schluss ein Liste zu generieren mit Grundinfos(Adresse) & Gruppenfeldern (Exceltool zum Zusammenkopien hab ich schon) direkt in CT wäre schöner.
Gut wäre wenn Gruppenfelder im Profil angezeigt werden.
MFG Patrick
-
Hallo, ist das mittlerweile möglich?
-
@MichaelG Sowas lässt sich ja gut über eine Merkmalsgruppe behandeln.
-
@bwl21 sagte in DB-Feld-Kategorie:
@MichaelG Sowas lässt sich ja gut über eine Merkmalsgruppe behandeln.
Wir hatten grad mehrere Mails mit dem Support hin und her mit dem Ergebnis, dass wir auf Custom Fields gehen müssen
Szenario: wir haben drei Gruppen, in die einen Person kommt, wenn sie an einem Kurs teilgenommen hat. Der Kurs hat also drei Teile.
Die Person selbst soll sehen, dass sie Teil dieser Gruppe ist (optional).
Leiter der Person sollen sehen, dass ihre Leute Teil dieser Gruppe sind. Die Leiter dürfen aber nur die Personen sehen, die sie bereits durch andere Rechte sehen dürfen. Diese Gruppe darf also keine Personen sichtbar machen, die ich nicht sehen darf.Ziel: Leiter sollen sehen, wer von ihren Leuten bereits am Kurs teilgenommen haben.
Diese Szenario ist bewusst von CT ausgeschlossen.
Jetzt hat ein genialer Kopf ein Skript geschrieben, dass das Teilnahmedatum einer Person alle x mal in das jeweilige custom field schreibt.
Um es nun übersichtlicher zu machen, würde ich die drei Felder nun unter einer Kategorie gruppieren
-
@MichaelG sagte in DB-Feld-Kategorie:
Die Person selbst soll sehen, dass sie Teil dieser Gruppe ist (optional).
Leiter der Person sollen sehen, dass ihre Leute Teil dieser Gruppe sind. Die Leiter dürfen aber nur die Personen sehen, die sie bereits durch andere Rechte sehen dürfen. Diese Gruppe darf also keine Personen sichtbar machen, die ich nicht sehen darf.Ziel: Leiter sollen sehen, wer von ihren Leuten bereits am Kurs teilgenommen haben.
Diese Szenario ist bewusst von CT ausgeschlossen.
Ja, das ist ein Problem. Solche Anforderungen haben wir auch. Ob das bewusst ausgeschlossen ist, oder einfach noch nicht angefordert und umgesetzt ...
Verallgemeinert müsste man ein Recht haben, Personen in einer bestimmten Gruppe zu sehen, wenn man die Person an sich schon sehen darf.
Der verallgemeinerte Anwendungsfall ist: Es gibt Gruppen in denen Sachen einer Person dokumentiert sind, die ein Leiter dieser Person sehen können soll. Anwendung ist
- Schulungsteilnahmen
- Präventionsmassnahmen
- Zustimmungen
- Allgemeine Angaben bei Kongressen (Mahlzeiten, Übernchtungen. usw.)
Das ist so ähnlich wie (view Group) nur dass man die Person eh schon sehen können muss:
Im vorigen Beispiel gibt es Arbeitsbereiche (ca 50) und Allgemeine Gruppen. Die Anforderung ist, dass jemand der eine Person sehen kann, auch die Gruppenmitgliedseigenschaften in den AA - Gruppen sehen kann. In den AA-Gruppen sind wiederum insgesamt ca 20 Felder drin.
Just gerade versuche ich das so zu lösen, dass ich über eine Automatisierung die Felder aus den AA-Gruppen in ein Kommentarfeld der jeweiligen Arbeitsgruppe einspiele ...
Aber es wäre viel einfacher, wenn es ein Recht gäbe ähnlich wie sichtbare Gruppenmitglieder sehen (
view visible groupmember) ähnlich wie (view group), nur dass es nicht die Sichtbarkeit der Person herbei führt.Dabei bleibt aber das Problem, dass der Leiter das direkt bei seinen Gruppenmitgliedern sehen will, ohne noch mal in einer anderen Gruppe nachschauen zu müssen. Vielleicht ist daher tatsächlich ein Custom-Feld bei den Personen wie ihr das gerade plant, die bessere Lösung. Wirft natürlich die Frage auf, ob man die Felder nicht gleich bei der Person pflegen sollte ...
Das skaliert halt nicht so gut, wie wenn man das in Merkmalsgruppen macht. Stell dir vor du hast x verschiedene Schulungen, da kriegst du ganz schnell zig Custom-Felder bei den personen ...
-
@bwl21 zumindest hat uns das der Support so bestätigt, dass diese Verhalten bewusst ausgeschlossen ist.
Aber ja, das, wie du es beschreibst, benötigt es für unseren Fall.
Wir sind nach wie vor auf Gruppen angewiesen u.a. wegen der automatischen Mails. Deswegen reicht es nicht ein custom field händisch zu pflegen. Damit ist die Gruppenteilnahme „führend“ und das Geld wird nur zur Ansicht synchronisiert.
Aber ja, bei zu vielen Dingen ist diese Lösung keine Lösung. Für uns taugt es in diesem Fall, weil es, einfach gesprochen, so etwas wie unser Mitgliedschaftskurs ist. Deswegen ist die Einsicht für Leiter darauf essenziell.
