Berechtigungskonzept

Gruppen / Rollen - Wie funktioniert das?

In hitobito können komplexe hierarchische Organisationen abgebildet werden. Alles basiert darauf, dass wir verschiedene Gruppentypen zulassen, welche auch definieren welche Rollen zur Verfügung stehen.

• Jede Organisation kann aus mehreren Ebenen bestehen, z. B. Dachverband, Kantonalverband (, optionale Zwischenstufen wie Regionen) und Ortsgruppen.

• Jede Ebene kann intern wieder ihre innere Struktur haben, es gibt einen Vorstand, Arbeitsgruppen, Mitgliederlisten, Kontaktlisten.

• Jede Person hat eine oder mehrere Rollen. Diese Rollen definieren, wen man sehen kann, und von vom man gesehen wird.

Hier einige Beispiele, wie das aussehen kann.

Karin ist Geschäftsleiter direkt im Dachverband

technisch: layer_and_below_full direkt in Dachverband, inkl. contact_data

Karin sieht:

Karin hat vollen Zugriff auf ihrer Ebene und auf alle darunter liegenden Ebenen. Dadurch kann sie alle Personen im Dachverband, in Regionen und auf oberster Ebene der Ortsgruppen sehen und ändern. Nicht sichtbar und änderbar sind für sie alle Personen, die innerhalb einer Ortsgruppe, also in einer Untergruppe unter der Ortsgruppe, aufgehängt sind. Da Karin’s Rolle als kontaktrelevant geführt ist (sog. ContactData-Flag, siehe unten), kann sie alle anderen Personen mit Kontaktrelevanz sehen, unabhängig von deren Position innerhalb der Struktur.

Karin sehen:

Karin ist für alle anderen Personen mit Rechten innerhalb der Ebene des Dachverbands sichtbar. Auf Grund der Kontaktrelevanz von Karin’s Rolle ist sie ebenfalls für alle anderen kontaktrelevanten Rollen sichtbar.

Luca ist ein Mitglied in einem Gremium im Dachverband

technisch: group_read in Gremium ohne contact_data

Luca sieht:

Luca sieht alle Mitglieder und Leitung innerhalb des Gremiums. Sonst sieht er niemanden ausserhalb des Gremiums.

Luca sehen:

Luca ist für Personen mit vollen Rechten (layer_full oder layer_and_below_full) für die Dachverbandsebene sicht- und änderbar. Zusätzlich kann die Leitung innerhalb seines Gremiums seine Daten einsehen und ändern (group_full). Seine Kollegen mit gleicher Rolle im Gremium sehen seine Daten, können diese aber nicht ändern (group_read)

Maria hat eine Rolle in der Region

technisch: group_read inkl. contact_data

Maria sieht

Maria kann alle Mitglieder ihrer Gruppe sehen, also alle Mitarbeitenden auf Regionsebene.

Da Maria’s Rolle als kontaktrelevant geführt ist (sog. ContactData-Flag, siehe unten), kann sie alle anderen Personen mit Kontaktrelevanz sehen, unabhängig von deren Position innerhalb der Struktur.

Maria sehen

Maria ist für alle anderen Personen mit Rechten innerhalb der Ebene des Dachverbands sichtbar. Auf Grund der Kontaktrelevanz von Maria’s Rolle ist sie ebenfalls für alle anderen kontaktrelevanten Rollen sichtbar.

Petra leitet ein Gremium in der Region

technisch: layer_read inkl. contact_data

Petra sieht:

Petra sieht alle Personen in der Region inkl. Personen in allfälligen Untergruppen. Sie sieht jedoch keine Personen in Ortsgruppen, welche der Region angehängt sind.

Da Petra’s Rolle als kontaktrelevant geführt ist (sog. ContactData-Flag, siehe unten), kann sie alle anderen Personen mit Kontaktrelevanz sehen, unabhängig von deren Position innerhalb der Struktur.

Petra sehen

Petra ist für Personen auf kantonaler oder Dachverbandsebene sichtbar, welche eine Rolle mit Zugriff auf untergeordnete Ebenen besitzen (layer_and_below). Zudem sehen alle Personen in der Region, die Rechte innerhalb der Gruppe oder der Ebene besitzen, ihre Daten.

Auf Grund der Kontaktrelevanz von Petra’s Rolle ist sie ebenfalls für alle anderen kontaktrelevanten Rollen sichtbar.

Anna leitet eine Ortsgruppe

technisch: layer_full incl. contact_data

Anna sieht

Anna sieht alle Personen innerhalb der Ortsgruppe.

Da Anna’s Rolle als kontaktrelevant geführt ist (sog. ContactData-Flag, siehe unten), kann sie alle anderen Personen mit Kontaktrelevanz sehen, unabhängig von deren Position innerhalb der Struktur.

Anna sehen

Anna ist für Personen oberhalb der Ortsgruppe sichtbar, falls diese das Recht besitzen, Personen unterhalb ihrer Ebene zu sehen. Zudem können ihre Kolleginnen und Kollegen innerhalb der Ortsgruppe ihre Daten sehen, falls sie das Recht für die Gruppe oder die Ebene besitzen. Auf Grund der Kontaktrelevanz von Anna’s Rolle ist sie ebenfalls für alle anderen kontaktrelevanten Rollen sichtbar.

Franz leitet eine Einheit innerhalb einer Ortsgruppe

technisch: layer_read (ohne contact_data)

Franz sieht

Franz sieht alle Personen innerhalb der Ortsgruppe, kann diese aber nicht ändern.

Franz sehen

Franz ist für Personen in der Ortsgruppe sichtbar, falls diese das Recht besitzen, Personen innerhalb der ganzen Ebene zu sehen. Personen oberhalb der Ortsgruppe können Franz nicht sehen.

Jonas ist Mitglied innerhalb einer Gruppe in der Ortsgruppe

technisch: none

Jonas sieht

Jonas sieht keine weiteren Personen.

Jonas sehen

Jonas ist für Personen in der Ortsgruppe sichtbar, falls diese das Recht besitzen, Personen innerhalb der ganzen Ebene zu sehen. Personen oberhalb der Ortsgruppe können Jonas nicht sehen.

Kumulierung von Rollen innerhalb der Struktur

Die Zugriffe durch mehrere Rollen kumulieren sich. So ist ein Mitglied einer Ortsgruppe, das gleichzeitig in der Region aktiv ist, trotzdem für die Regionsleitung sichtbar.

Daten in Anlässen (Lagern, Kursen)

Teilnehmer in einem Anlass können die Teilnehmerliste einsehen und sehen dort ihre gegenseitigen Kontaktdaten. Die Daten sind nur im Kontext „Anlass“ sichtbar, wenn über die Teilnehmerliste zur Person navigiert wird. Im Kontext einer „Gruppe“, wenn über die Gruppenhierarchie zur Person navigiert wird, gelten die Zugriffsrechte gemäss den strukturbasierten Rechten oben.

Spezialfall Contact_Data

Ist die Rolle einer Person als kontaktrelevant markiert, so hat diese Person auf alle anderen Personen mit kontaktrelevanten Rollen Zugriff. Gleichzeitig ist sie auch für alle anderen Personen mit kontaktrelevanten Rollen sichtbar. Dies umfasst Rollen, welche häufig im Austausch mit Personen aus anderen Ortsgruppen stehen.

Spezialfall finance

Erlaubt auf der entsprechenden Ebene Rechnungen zu erstellen und einzusehen.

Spezialfall impersonation

Darf andere Accounts temporär übernehmen, z. B. für Support Aufgaben oder für Tests. Dies ist eine sehr mächtige Funktion und sollte nur an klar definierte Rollen vergeben werden.

Security: Zugriffsanfragen und manuelle Freigabe

Angenommen, Anna möchte unberechtigt Zugriff auf die persönlichen Daten von John bekommen. Dazu kann Anna John einfach in einer Gruppe, einem Anlass oder Abo hinzufügen, in der sie Zugriffsrechte hat. Dieses Datenschutz-Problem kann in hitobito mit den „manuellen Freigaben“ verhindert werden.

Beim Hinzufügen von John in Gruppen, Anlässen und Abos überprüft hitobito Johns Haupt-Rolle (die Rolle die mit einem Stern markiert ist). Falls John keine aktive Rolle mehr hat, überprüft hitobito stattdessen die letzte Rolle die noch aktiv war. Es wird überprüft, ob in der Ebene dieser Rolle die manuellen Freigaben aktiviert sind. Beispiel: John hat seine Haupt-Rolle in der Arbeitsgruppe „Saturn“ des Vereins „Sterngucker Luzern“. Die manuellen Freigaben können bei der Ebene (Verein Sterngucker Luzern) auf dem Anfragen-Tab aktiviert werden.

Sind manuelle Freigaben in der Ebene aktiviert, dann wird John nicht direkt in die neue fremde Gruppe, Anlass oder Abo hinzugefügt, sondern es wird eine Zugriffsanfrage ausgelöst. Anna sieht dann folgende Nachricht:

Alle Personen die auf dem Anfragen-Tab ausgewählt sind, sowie John falls er einen Login hat, bekommen ein E-Mail welches darüber informiert dass Anna John an einem neuen Ort hinzufügen will. Von diesem E-Mail aus oder auf dem Anfragen-Tab der Gruppe kann die Zugriffsanfrage akzeptiert oder abgelehnt werden.

So bekommt Anna nie unberechtigten Zugriff auf die Personendaten von John. Das Ganze funktioniert aber nur, wenn die manuellen Freigaben auf der Ebene aktiviert sind. Es wird keine Zugriffsanfrage ausgelöst wenn Anna bereits vorher Zugriff auf John hat (z.B. wenn beide eine Rolle mit contact_data haben).