Sichtbarkeit Schwestergruppen ausschalten

[richardjubla]

Diese Story/Issue ersetzt den Teilbereich von Maintenance Package #50 für den Inkrement 2/24

Als FG Datenbank möchte ich ermöglichen und erzwingen, dass der Datenschutz in der jubla.db technisch eingehalten wird. Dazu soll die Sichtbarkeit (Exportierbarkeit) von “Schwestergruppen” eingeschränkt und wieder gemäss den geltenden Rollen und Berechtigungen (Hitobito Standard) funktionieren.

Grundsätzlich gilt: https://jubladb-handbuch.readthedocs.io/de/latest/datenschutz.html und https://jubladb-handbuch.readthedocs.io/de/latest/anleitung.html#wer-sieht-meine-daten

Primär verantwortlich für die Bearbeitung deiner Personendaten ist derjenige Verein von Jungwacht Blauring Schweiz, bei welchem du «direktes» Mitglied bist, konkret deine Schar. Weitere Verantwortliche sind der Regional- und/oder Kantonalverband deiner Schar sowie Jungwacht Blauring Schweiz. Sie sind gemeinsame Verantwortliche.
Als Mitglied einer Schar (lokaler Verein) bist du gemäss den jeweiligen Statuten auch Mitglied des dazugehörigen regionalen (sofern vorhanden), kantonalen und nationalen Verbands (Jungwacht Blauring Schweiz). Mitglieder des Netzwerks Ehemalige Jungwacht Blauring sind zudem auch Mitglied von Jungwacht Blauring Schweiz.
Nachfolgend wird in der «Wir»-Form gesprochen. «Wir» bezeichnet diejenige juristische Person, die verantwortlich ist für die Bearbeitung deiner Mitgliederdaten.

Daraus abgeleitet ergibt sich ein schlüssiges Berechtigungsmodell, welches die Berechtigungen nach oben weiterreichen darf. Berechtigungen zur Seite (auf der gleichen Ebene / Schwestergruppen) sind damit nicht abgedeckt. Wie bisher ist jeweils die übergeordnete Ebene für die Koordination der darunterliegenden Gruppen/Ebenen zuständig.

Aspekte

https://help.puzzle.ch/#ticket/zoom/5274

Definition of Done

• Die Anpassung der Sichtbarkeit von Schwestergruppen (aus dem Jahre 2015) ist wieder entfernt.
• Ticket https://help.puzzle.ch/#ticket/zoom/5274 ist einbezogen und gelöst
• Es ist überprüft und festgestellt, welche Abhängigkeiten durch diese Anpassung und deren Rückbau entstehen
• Puzzle hat und nimmt sich die Zeit/Verantwortung, die Situation zu erfassen und im Sinne der Aufgabe zu lösen
• Explizit: Alle "Tests" (zum Beispiel: person_ability_spec.rb) sind überprüft, aktualisiert und korrekt abgebildet
• Explizit: Jubla Organization Hierarchy (rake app:hitobito:roles) ist überprüft, aktualisiert und korrekt abgebildet

ToDo

• Sichtbarkeit der Schwestergruppen ausbauen
• Problem wie im Ticket beschrieben kann nicht mehr nachgestellt werden
• Specs anpassen
• README prüfen
• CHANGELOG erweitern

[richardjubla]

@ThomasEllenberger können wir eine Rückmeldung zum PR haben: #100 (comment)

[richardjubla]

Definition of Done nicht erreicht, Ticket für uns noch nicht abgeschlossen.

[richardjubla]

Erkenntnisse/Notizen:

• Bei neue Abos oder Anpassungen können keine Schwester-Gruppen oder Übergeordnete Gruppen mehr ausgewählt werden.
• Bestehende Abos bleiben bestehen und funktionieren (vielleicht) wie bisher. Im Export wird für manche Daten der Wert "fehlende Berechtigung" angezeigt, wenn das Profil nicht von der Rolle gelesen/geschrieben werden kann.
• Wird ein Profil (Kind, Schwesterschar) in ein Abo hinzugefügt, wird bei korrekter Konfiguration der "Anfragen" eine Anfrage ausgelöst. (Ohne die Freigabe, kann das Profil nicht dem Abo hinzugefügt werden)
• Die Globalen Bedingungen wirken nur innerhalb der Filter/Gruppen und ermöglichen keine Rechte-Ausweitung
• Menschen können nach "Name" oder "Vorname" gesucht werden.
• Für Profile "ohne Berechtigungen" gibt der CSV-Export Informationen zur Person preis (Vorname Nachname Ort Hauptebene Rollen etc.) die E-Mail-Adresse wird mit "fehlende Berechtigung" nicht veröffentlicht. Die E-Mail-Adresse ist aber im Export "E-Mail-Adressen" exportierbar.
• Der Export "E-Mail-Adressen" gibt die E-Mail-Adresse für jedes beliebige Profil aus, welches irgendwie in den Verteiler hinzugefügt wird (nach Profi suchen, auch Kinder-Profile)
• Die Abo-Suchfunktion funktioniert "Global" und gibt die Vornamen, Nachnamen, Ort und Geburtsjahr für jegliche Suchanfragen aus. Wir verstehen, dass einem Abo auch global Profile hinzugefügt werden wollen/sollen, sehen aber nicht gerne, wenn selbst eine Gruppenleitung globale Suchabfragen tätigen kann.
• Abos funktionieren "korrekt" auch bei fehlenden Berechtigungen. Vermutlich soll einem Abo zugeteiltes Profil auch die E-Mail erhalten, aber eben die Profil-Daten nicht an den Abo-Admin preisgeben.
• Gedanke: Ein Profil sollte ein Abo selbst global abonnieren können, falls dies technisch möglich ist. Ein Profil sollte aber nur zu einem Abo hinzugefügt werden können, sofern dies durch Rollen/Berechtigungen erlaubt ist. Ein Profil "teilt" mit dem Abo-Export ausschliesslich öffentliche Daten (seine E-Mail-Adresse) oder gemäss den erlaubten Daten durch Rollen/Berechtigungen welches das exportierende Profil besitzt. (Abo = Opt in zur Kommunikation und Nicht Opt in für alle Profildaten)

[richardjubla]

Bei Abos sollten Gruppen neu nur unterhalb der Abogruppe ausgewählt werden können. Der Text in der jubla.db dazu ist wohl nicht angepasst worden: https://github.com/hitobito/hitobito/blob/13187add80f0fe32bc488c0d357b7b5f46ba7840/config/locales/views.de.yml#L1985

[richardjubla]

Gemäss Support gibt es die Funktion "Zugriffsanfragen für Abos". (in hitobito-demo, jubla-wagon & cevi sind Zugriffsanfragen nicht aktiv und als Feature bekannt: hitobito/hitobito#1653 )
Falls Zugriffsanfragen für Abos aktiviert würde, könnten nur durch Erlaubnis des Profils eine Zuteilung in ein Abo erfolgen.

[kronn]

Der Hilfetext wurde beim Deaktivieren des Features übersehen, vielen Dank für den Hinweis.

Die Zugriffsanfragen werden nicht direkt auf den Abos aktiviert. Wenn eine Gruppe Zugriffsanfragen aktiviert hat, gelten diese auch für das Hinzufügen von Personen, die aus diesen Gruppen kommen und direkt zu einem Abo hinzugefügt werden sollen. Wer "Schreibrechte" auf einer Person und dem Abo hat, darf jedoch auch ohne Zugriffsanfrage die Person hinzufügen.

Sollen ähnlich wie in hitobito/hitobito#1653 entsprechende Zugriffsanfragen eingeschaltet werden? Wenn es nicht bei allen Gruppen aktiviert werden soll, wäre es vermutlich leichter, die selbst in den fraglichen Layergruppen zu aktivieren.

Da der Hilfetext korrigiert wurde, würde ich dieses Ticket hier schliessen. Die Zugriffsanfragen sollten besser in einem neuen, dedizierten Issue festgehalten werden.

[richardjubla]

Der Hilfetext wurde beim Deaktivieren des Features übersehen, vielen Dank für den Hinweis.

Danke

Die Zugriffsanfragen werden nicht direkt auf den Abos aktiviert. Wenn eine Gruppe Zugriffsanfragen aktiviert hat, gelten diese auch für das Hinzufügen von Personen, die aus diesen Gruppen kommen und direkt zu einem Abo hinzugefügt werden sollen. Wer "Schreibrechte" auf einer Person und dem Abo hat, darf jedoch auch ohne Zugriffsanfrage die Person hinzufügen.

Wer ein Abo verwalten darf, kann über die gesamte Datenbank Profile suchen und zum Abo hinzufügen. Sofern er den Namen kennt oder erraten kann, benötigt er dazu keine Rollen oder Berechtigungen. (Bestätigte Erkenntnis gemäss Helpdesk Ticket 20.10.22, Expliziter Bestandteil dieser Offerte/Ticket)
Aktuell auf Stage-Umgebung reproduzierbar: In Abos können auch Profile aus x-beliebigen und fremden Gruppen mit der Rolle Extern gefunden und hinzugefügt werden (Die Rolle Extern ist nur von Personen in der selben Ebene sichtbar, nicht von Personen aus darüber liegenden Ebenen). Teilweise sind die Profil-Daten dann mit dem Wert "fehlende Berechtigung" ersetzt, eine eindeutige Identifizierung des Menschen nach SR 235 Art. 6 aber nicht Dokumentiert oder Erkennbar.

Zur Unterstützung habe ich unser Handbuch ergänzt bzw. präzisiert um den Umstand, dass auch Abos zu einer Weitergabe von Daten führen: jubla-ch/handbuch-jubladb-hitobito@da1dba1

Sollen ähnlich wie in hitobito/hitobito#1653 entsprechende Zugriffsanfragen eingeschaltet werden? Wenn es nicht bei allen Gruppen aktiviert werden soll, wäre es vermutlich leichter, die selbst in den fraglichen Layergruppen zu aktivieren.

Unser Zeil ist es weiterhin, dass Profil-Daten aus fremden Gruppen (Schwestergruppen) nicht ohne die Einwilligung/Kenntnis durch das Profil selbst und in der Verantwortung durch den Vorstand "weitergegeben" werden. (hitobito Dokumentation zu Abos beschreibt diese Funktion nicht: https://hitobito.readthedocs.io/de/latest/mailing_lists.html es ist als eigenständiges Thema erwähnt als Vorstands-Aufgabe: https://hitobito.readthedocs.io/de/latest/access_concept.html#security-zugriffsanfragen-und-manuelle-freigabe ) Sofern Zugriffsanfragen eine/die Option sind, sollten wir diese Möglichkeit auf jeden fall einbeziehen.

Da der Hilfetext korrigiert wurde, würde ich dieses Ticket hier schliessen. Die Zugriffsanfragen sollten besser in einem neuen, dedizierten Issue festgehalten werden.

Ich werde mit @ThomasEllenberger das weitere Vorgehen besprechen.

[richardjubla]

Ziel/Auftrag aus Sicht Jubla nicht erreicht. Einzige Lösung ist als Ergänzung/alternative in Folgeticket #106