nicht hierarchische Sicherheitslevel hinzufügen
-
Ich würde mir wünschen Sicherheitslevel hinzuzufügen, die nicht aufeinander aufbauen, also zum Bespiel Stufe 2a, Stufe 2b etc. Derjenige, der Daten mit Sicherheitslevel 2b sieht kann nicht Daten mit Sicherheitslevel 2a sehen und umgekehrt.
Hintergrund ist, dass für verschiedene Dienste in der Gemeinde verschiedene Personenbezogenen Daten wichtig sind. Zum Beispiel soll der Kinderdienst die Kontakt-Daten der Erziehungsbeauftragten sehen oder das Medienteam ob von einer bestimmten Person die Fotoerlaubnis vorliegt usw. Aber die Teams sollen dabei jeweils nicht Zugriff auf die anderen Informationen haben, die sie gar nicht brauchen (Datensparsamkeit).
Soweit ich das bisher gesehen habe, kann man zwar weitere Sicherheitslevel hinzufügen und auch die Berechtigungen für die einzelnen Level einzeln vergeben, aber man bekommt automatisch alle darunterliegenden Berechtigungen (das heißt bei neu erstellten Leveln Stufe 4 plus alle vorher erstellten Sicherheitslevel). Dies wird in der Rechtevergabe allerdings nicht angezeigt. Es wäre schön, wenn es möglich wäre, dass man die Rechte für die einzelnen Stufen wirklich einzeln vergeben könnte.
Falls das nicht geht, wäre es sehr gut, wenn wenigstens die entsprechenden Haken automatisch gesetzt werden, also wenn man jemanden das Recht gibt Level 3 zu sehen, dass dann automatisch der Haken bei Level 2 und Level 1 mit gesetzt wird, da dass ja rein praktisch im System auch automatisch umgesetzt wird, aber bisher nicht angezeigt wird.
-
@fjthmk95 So ganz verstehe ich dein Anliegen nicht. Das, was du beschreibst, geht m. E. doch mit den vorhandenen Leveln. Du kannst alle DB-Felder doch nach deinen Wünschen den Leveln zuweisen.
Oder übersehe ich etwas?
-
Ah ... Moment ... du hast für die Fotoerlaubnis ein eigenes DB-Feld angelegt? Gut, das müsste dann in der Tat Level 1 bekommen und damit würde dieses Feld für jeden sichtbar sein, der mind. Level 1 hat.
Üblicherweise löst man das allerdings über Gruppen und dann würde dieses Problem an der Stelle gar nicht auftreten.
-
Wir versuchen personenbezogene Daten nicht über Gruppen abzubilden, da das einerseits nicht über "eigenes Profil bearbeiten" veränderbar ist und es andererseits zu viele Gruppen bedeuten würde, da wir verschiedene Standorte und verschiedene Kindergruppen haben und z.B. die Leiter der Kindergruppen wissen müssen, wer der Kinder fotografiert werden darf, aber sie natürlich das nicht von der gesamten Gemeinde wissen sollen.
Weiteres Beispiel ist zum Beispiel die CheckIn-ID weiter, die jedem Kind zugeordnet ist und beim Gruppenwechsel erhalten bleibt, also nicht an eine Gruppe gebunden sein kann und trotzdem von einem sehr eingeschränkten Personenkreis gesehen werden soll. Dieser Personenkreis soll aber von den restlichen Daten der Kinder nichts weiter sehen.
Ein weiterer Anwendungsfall ist außerdem, dass man Personen erlauben kann, ihre eigenen Daten aktuell zu halten. Manche Daten wie zum Beispiel die CheckIn-ID oder Eintrittsdatum dürfen von den Personen aber auf jeden Fall nicht geändert werden. Dies geht derzeit nur, wenn man entweder die Person nur sehr eingeschränkt ihre eigenen Daten bearbeiten lässt (was höheren Aufwand für viele Änderungen bedeutet) oder wenn man den Leuten, die Zugriff auf nicht änderbare Daten geben will, sehr weitreichende Rechte gibt Personendaten zu sehen (was natürlich vom Datenschutz nicht machbar ist)
-
Ich würde das hier gerne nochmal pushen und ein bisschen unsere Bedürfnisse dazu erklären:
wir haben aktuell nochmal eine neuaufkommende Diskussion zur Sichtbarkeit von Daten.. da wir CT zur Mitgliederverwaltung und als Adressen- und Geburtstagsliste verwenden wollen, haben wir das Problem, dass von manchen Mitgliedern Daten vorgehalten werden müssen, diese aber nicht automatisch deren Veröffentlichung zustimmen müssen. Außerdem werden die Pfilchtfelder in einem eigenen Sicherheitslevel Stufe 2 (nicht bearbeitbar) vorgehalten.
Freunde sehen aktuell nur Stufe 1, Mitglieder Stufe 2 (nicht bearbeitbar).Die Zustimmung zur Veröffentlichung des Geburtstages, haben wir aktuell als eine Merkmal-Gruppe abgebildet. Eine Idee, um die Sichtbarkeit von den Geburtstagen einzuschränken wäre also gewesen, das Geburtstagsfeld in ein eigenes Sicherheitslevel zu packen und das dann Merkmals-intern frei zugeben. Aber wo in der Hierarchie gehört das Sicherheitslevel jetzt hin?
Über Stufe 2 (nicht bearbeitbar) würden wir Freunden doch plötzlich Zugriff zu sehr viel mehr Informationen geben, unter Stufe 2 (bearbeitbar) wäre das Geburtstagsfeld plötzlich bearbeitbar. Das ist wieder ungünstig, weil wir das Datum für die Mitgliederverwaltung brauchen.
Selbst wenn wir da einen passenden Ort finden würden - was passiert, wenn wir die Adresse nur innerhalb eines Adresssichtbarkeits-Merkmales freigeben wollen? Das geht nicht, da sonst immer die Adressseher auch das Geburtsdatum sehen oder eben anders herum.Von diesen technischen Grenzen des aktuellen Systems einmal abgesehen, passt ein nicht hierarchisches Sicherheitslevel system (was dann wohl einen neuen Namen bräuchte) wohl auch ein bisschen besser in die Rechteverwaltung, da hier einzelne Ebenen auswählbar sind (und es nicht auf den ersten Blick klar ist, dass alle anderen Level darunter implizit aktiviert sind - was die alphabetische Sortierung auch nicht besser macht, wenn man die Ebenen nicht Stufe X benennt :)).
-
@fodinabor man kann doch die Berechtigungen für jeden Level einzeln angeben - zumindest bei den globalen Berechtigungen.
Bei den gruppeninternen Berechtigungen geht das wohl nicht.
-
@bwl21 gerade kriege ich mit, dass man die levels zwar separat anwählen kann, sie aber wohl doch hierarchisch sind.
