Globale Berechtigungen an Untergruppen vererben
-
@gunnar, @paul_rum Followup zu https://forum.church.tools/topic/6675/globale-berechtigung-an-untergruppe-vererben?_=1611328817535
Wir sind auch gerade an dem Thema. Ich hatte die Absicht spezielle Rechtegruppen anzulegen und über diese globale Recht in verschiedene Gruppen einmischen (sozusagen Mixins) zu lassen. Auf diese Weise würde eine "Fähigkeit" (nämlich Operation x an Sache y auszuführen) genau einmal gepflegt und in verschiedenen Gruppen angewandt werden.
Ich wollte die relativ detaillierte Rechte-Einstellung auf dieses Weise abstrahieren. Da eine Gruppe mehrere Obergruppen haben kann, hätte ich darin die Rechte schön organisieren können. Jetzt habe ich festgestellt, dass globale Berechtigungen nicht vererbt werden können.
Eine Lösung über Gruppentypen ist nicht so elegant bzw. nicht möglich, weil m.E. eine Gruppe nur genau einen Gruppentyp haben kann. Ein Gruppentyp deckt ja eine kombination verschiedener Aspekte ab, nicht nur die Zugriffsberechtigungen. Das ufert schnell aus, ohne die erwähnte Mehrfachpflege zu vermeiden.
Daher nun Feature-Wunsch dass man auch globale Rechte an Untergruppen vererben kann.
Anwendungsbeispiel - zugegebenermassen konstruiert:
Die "Räume im Keller" dürfen nur von "Musikern" und "Sportlern" gebucht werden. Musiker und Sportler haben sonst gar keine Gemeinsamkeiten. Der Begriff "Keller" drückt sich in einer Auflistung von einzelnen Räumen aus. Buchen meint den Zugriff auf bestimmte Wiki-Seiten, bestimmte Kalender und bestimmte Resourcen.
Ich würde nun eine Gruppe anlegen "RG_Kellerraum-buchen", und dort die recht komplexe einstellung der Rechte vornehmen.
Diese Gruppe "RG_Kellerraum-buchen" würde ich dann als eine Obergruppe (mit vererbungstiefe 1 - eingestellt im Gruppentyp RG) zu "AG_Sportler" und "AG_Musiker" setzen und wäre fertig.
Dann mag es noch den Fall geben, dass die Notenblätter von "Musikern" und vom "Gemeindebüro" gelesen werden können. Also würde ich eine Rechtegruppe "RG_Notenblätter-lesen" anlegen und diese als Obergruppe für "AG_Musiker" und "OG_Gemeindebüro" machen.
Auf diese Weise werden die Fähigkeiten, "Kellerräume buchen" und "Notenblätter-lesen" "Protokolle-bearbeiten" separat behandelt, aber nur einmal definiert und in die jeweiligen Gruppen eingefügt.
Das sieht dann also so aus:
Dieser Featurewunsch kommt aus dem, was ich in CT wahrnehme. Das ganze könnte man auch ganz anders lösen, ohne die Gruppen zu "missbrauchen". Andererseits sind die Gruppen ein sehr genrischer Mechanismus.
Da andererseits die Rechtevergabe ein relativ zentales ding ist könnte man auch so vorgehen, dass Gruppenbeziehungen mit einer expliziten Semantik versehen werden können.
Dann wäre
AG__Musiker -|>RG__Kelleraum_buchen
nicht nur eine einfache Obergruppe, sondern eine sowas wieAG__Musiker -erbt rechte von -|> RG__Kerllerraum_buchen
-
ich muss das nochmal pushen. Hat mir jemand eine Tipp, wie man das lösen kann?
-
Ich löse das momentan mit Gruppentypen, die ich entsprechend berechtige. Vererbung wäre der schönere Weg, aber so funktioniert es auch.
-
@paul_rum hi paul Danke für die Rückmeldung. Wie machst du das mit Gruppentypen? die AG-Musiker kann ja nur genau ein Gruppentyp haben. bräuchte aber RG_Kellerraum_buchen und RG_Notenblaetter_lesen.
-
Nur eine spontante Idee: Wie wäre es, "Merkmale" zu verwenden?
(quasi eine Art "Marker-Interfaces") -
@Simon2 verstehe nicht, was du meinst. Hab ich da ein Konzept in CT übersehen? Das wäre ja super.
Wir haben im Vorfeld schon ein Verfahren über das wir die notwendigen Berechtigungen bestimmen. Wir gehen durch die Abläufe durch und schreiben User stories. Daraus kann man dann erforderliche Berechtigungen ableiten. Details würden hier zu weit gehen.
Letztendlich muss ich aber das Ergebnis auf die Möglichkeiten der Berechtigungssteuerung von CT abbilden. Und läuft m.W. auf den Ebenen "Status" "gruppentyp", "gruppe(rolle)", "person".
Da wir an einzelne Personen keine Berechtigungen vergeben wollen (zumindest noch nicht) bleibe ich bei der "Gruppe" hängen.
-
@bwl21 Es gibt den Gruppentypen "Merkmal" ... da kann man "Merkmale" anlegen und an die genauso Berechtigungen hängen wie an alle anderen Gruppentypen.
-
@Simon2 sorry, stehe gewaltig auf dem Schlauch. Ich finde nicht, wie ich einem Gruppentyp (oder einer Gruppe) Merkmale geben und an die Merkmale dann Berechtigungen klemmen kann.
-
@bwl21 Wie gesagt: Ich habe nur rudimentär verstanden, was du brauchst.
Bei mir kann ich jedenfalls einer Gruppe auch ein Merkmal als "übergeordnete Gruppe" zuordnen.
Und in der Rechteverwaltung kann man modellieren, welche Rechte an "untergeordnete Gruppe" weitergegeben werden... -
@Simon2 bei mir sieht das so aus
d.h. ich kann nur eine übergeordnete Gruppe auswählen. Allerdings werden von dieser Übergeordneten Gruppe nur die Gruppgenberechtigungen vererbt, nicht aber globalen Berechtigungen.
-
@bwl21 Also ich habe keine Probleme, einer Gruppe weitere übergeordnete Gruppen (vom Typ "Merkmal") zuzuordnen. Muss halt mehrmals durch den o.g. Dialog laufen ("Kreuz drücken").
. -
@Simon2 ich sehe, ihr habt
- einen Gruppentyp
Nochnmerkmal
angelegt. - an dieses Merkmal hängt ihr Berechtigungen
- Von dieser Typ habt ihr eine Gruppe
WirTestenChurchtools_specRights
angelegt WirTestenChurchtools_specRights
ist dann eine Übergeordnete Gruppe vonWirTestenChurchtools
Habt ihr ausprobiert, ob globale Berechtigungen, die ihr über den Gruppentyp
Nochnmerkmal
setzt, auch bei den Mitgliedern vonWirTestenChurchtools
ankommen?Bei gruppeninternen Berechtigungen funktioniert es, aber m.W. werden globale Berechtigungen nicht vererbt.
Da bin ich echt gespannt. Das könnte dann in der Tat eine Lösung sein - ein klein bisschen umständlich, aber gangbar - vorausgesetzt es funktioniert ...
- einen Gruppentyp
-
@bwl21 nicht ganz: Ich habe eine weitere Gruppe (vom Gruppentyp "Merkmal") mit dem Namen "Nochnmerkmal" angelegt - nur für den Zweck, das hier zu zeigen (gleich danach wieder gelöscht).
Ich habe keinen Bedarf an ausgetüftelteren Berechtigungen und habe deshalb auch nicht weiter herumprobiert.
Wollte nur auf ein Feature hinweisen, das dir vielleicht helfen könnte. -
@Simon2 Im Gegensatz zu deiner recht neuen ChurchTools Instanz habe ich eine Instanz geerbt. Hier werden einfach nur die Standard Gruppentypen verwendet und alles mit gruppenspezifischen Rechten gelöst, nix vererbt. Auch Personen haben Rechte bekommen anstelle nachzudenken, in welche Gruppe sie den müssten oder welche Gruppen man erschaffen müsste ...
Ich plane aktuell die Zahl der Gruppentypen aufzubohren und 99% aller gruppenspezifischen Rechte zu löschen. Keine Ahnung ob das klappt.Den Tipp mit Merkmal finde ich nicht schlecht, nur funktioniert es meines Wissens nur bei Personen und nicht bei Gruppen. Also alle Musiker bekommen neben der Gruppe AG_Musiker auch das Mekrmal "Darf Keller buchen". Alle Musiker, bei denen man das vergisst dürfen dann halt noch nicht buchen ... nicht schlimm, da die Merkmale sehr explizit sind und man bei bestehenden Musikern sehen kann, welche Merkmale sie haben.
Wenn du es nicht selber programmierst wirst du immer herum tüfteln müssen, außer du hast nur ganz einfache Anwendungsfälle. Viele unserer Mit-Admins haben keinen blassen von Vererbung und fänden das viel zu Abstrakt, auch wenn wir beide es elegant fänden. So habe ich das am Arbeitsplatz kennengelernt. Mein abstraktes Denken ist für mich normal und für andere gerade so nachzuvollziehen aber etliche winken gleich ab. Freu dich, dass es dir gegeben ist!
-
@bwl21 schau dir mal diese FR an
https://forum.church.tools/post/24609
Ich denke, dass die Grundidee deiner Problematik hilft.
Du würdest dann einen Gruppentyp „Berechtigung“ anlegen und dort je eine Gruppe pro Rechtepaket.
Die Teilnehmer dieser Gruppen setzen sich dann aus den Filtern zusammen, so dass man die wildesten Konstellationen bilden kann.In einem Post hat der P.O. schon mal angedeutet, dass er sich vorstellen kann, das Thema anzugehen, wenn im gleichen Zuge die Bereiche-Funktion gestrichen wird.
Also Voten kommentieren und mit uns auf das Feature hinarbeiten
-
@MichaelG sagte in Globale Berechtigungen an Untergruppen vererben:
In einem Post hat der P.O. schon mal angedeutet, ...
PO hier: Product Owner (schönes neues deutsches Wort )
Von meiner SrumMaster Ausbildung und von Antworten des Supports erschließe ich mir, dass es mehrere Product Owner für Teile der ChurchTools-Anwendung gibt. -
@MichaelG HI Michael, die Anforderung ist ja schon aus 2013 ... Ich fürchte das kommt nicht so schnell. Daher muss ich weiter nach einer Lösung suchen, die ich jetzt umsetzen kann.
-
@Gunnar sagte in Globale Berechtigungen an Untergruppen vererben:
Den Tipp mit Merkmal finde ich nicht schlecht, nur funktioniert es meines Wissens nur bei Personen und nicht bei Gruppen. Also alle Musiker bekommen neben der Gruppe AG_Musiker auch das Mekrmal "Darf Keller buchen". Alle Musiker, bei denen man das vergisst dürfen dann halt noch nicht buchen ... nicht schlimm, da die Merkmale sehr explizit sind und man bei bestehenden Musikern sehen kann, welche Merkmale sie haben.
offensichtlich hast du das mit den Merkmalen verstanden. Ich leider nicht. In meiner instanz gibt es keinen Gruppentyp "Merkmal". Den könnte ich zwar anlegen, ich kann aber nicht erkennen, wie mir das weiter helfen würde. Sorry, stehe da ganz auf dem Schlauch.
Irgendwie brauch ich vielleicht mal ein ER-Diagramm oder Klassendiagramm, um das ganze zu verstehen.
-
@bwl21 Ja, Merkmal ist ein beliebter Name eines Gruppentyps, der erst mal keine Rechte vergibt.
Als Merkmal habe ich:- "Hat Gemeindehausschlüssel", damit das nicht eine geheime Liste irgendwo im Schrank ist
- "Spender" - für meinen Kassenwart als Filter
- "Weggezogen" - alle Leute, deren Adressen wir behalten dürfen, obwohl sie weiter als 50km weg sind
- "Kein Smartphone" - die Armen, die man nie in einen Chat bekommt, trotz Mobilrufnummer
Im Prinzip habe ich damit angefangen, als ich zu viele Datenbankfelder angelegt hatte und nicht jeder alles sehen sollte, manche aber schon. Gruppen sehen dürfen kann man einfacher steuern als die Sicherheitslevels.
Ich würde nun eher einen Gruppentype "Rechte" erstellen, da jede einzelne Gruppe nur dazu da ist, dem Mitglied ein Recht oder ein Gruppe von Rechten zu geben.
-
@Gunnar ok, Merkmal ist also keine spezifische Funktion von CT, die ich nicht gefunden habe.
Ich würde nun eher einen Gruppentype "Rechte" erstellen, da jede einzelne Gruppe nur dazu da ist, dem Mitglied ein Recht oder ein Gruppe von Rechten zu geben.
Dieser Vorschlag deckt sch 100% mit meinem ursprünglichen Plan, nämlich die Rechte zur Bearbeitung von Kalendern, Events, Ressourcen in einer "Rechtegruppe" zu fassen. Da aber globaler Rechte nicht auf Untergruppen vererbt werden, muss ich nach gegebenem Stand die Mitarbeiter aus irgendwelchen Untergruppen nehmen und noch mal dieser "Rechtegruppe" zuordnen.
Ich sehe, du verstehst nun mein Problem.