New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PERSON: Automatisierte Datenlöschung #2106
PERSON: Automatisierte Datenlöschung #2106
Comments
Aus meiner Sicht darf das gerne in den Core - einfach die "10 Jahre"-Frist bitte konfigurierbar machen (in |
Neue Spezifikation: Auf Basis der Diskussion in #1299 und dem Issue hitobito/hitobito_pbs#273 möchten wir eine automatisierte Datenlöschung einrichten. Siehe auch #2105 für die manuelle Datenlöschung. Der Ehemaligenprozess (siehe hitobito/hitobito_pbs#273) wird durch diesen Prozess ergänzt, aber beide Prozesse sind grundsätzlich unabhängig. Falls aus dem Ehemaligenprozess keine Mitgliedschaft in einer Ehemaligengruppe resultiert, wird früher oder später der Archivierungsprozess gemäss den hier definierten Kriterien einsetzen. Der Prozess wird täglich angestossen, sofern mindestens die Kriterien 1-4 für eine Person erfüllt sind:
Falls 1-4 erfüllt sind, aber 5 nicht, wird der Datensatz der Person minimiert (siehe Grund dafür im Ticket #1299 (comment)). Dabei werden ausgewählte Felder auf Standardwerte zurückgesetzt. Standardmässig passiert bei Minimierung im Core noch nichts. Das Verhalten kann aber im Wagon-Code übersteuert werden. Minimierte Profile werden als solche im Backend markiert. Markierte Profile werden nicht erneut minimiert. Die Markierung wird aufgehoben, wenn eine Person eine Rolle erhält (Gruppe oder Event). Falls zusätzlich auch das fünfte Kriterium erfüllt ist, wird der Datensatz komplett gelöscht. Die Konsequenz davon ist, dass die Teilnehmerzahlen von vergangenen Events verfälscht werden. Dies könnte man verhindern, indem die Datensätze mit Standardwerten überschrieben anstatt komplett gelöscht werden. Auf vergangene Bestandesmeldungen hat die Löschung keinen Einfluss. Die Kriterien 1-4 sind Wagon-unabhängig und sollen wenn möglich im Core umgesetzt werden. Das Kriterium 5 ist hingegen eher auf den Youth- oder sogar PBS-Wagon ausgerichtet. Einzelheiten müssen geklärt werden. Im Idealfall sollte der Core beide Varianten (Minimieren, Löschen) kennen, jedoch sehr restriktiv damit umgehen. Die Wagons können damit ihre eigenen Kriterien implementieren und das Verhalten verschärfen. |
Sieht für mich sehr gut aus. Danke für deine Arbeit. Ich denke auch, dass der Effekt des Minimieren im Organisations-Wagen implementiert werden muss, da dort ja auch die zusätzlichen Felder definiert sind die wohl mit minimiert werden müssen. Es wäre sicher verwirrend, wenn ein Teil der Felder ohne spezifischen Wagon-Code minimiert würde, während andere erhalten blieben. Zum echten Löschen: Der Core hat doch auch bereits Anlässe. Entsprechend könnte das wohl schon auch im Core implementiert werden. Wie oben erwähnt, sehe ich da kein Problem, solange die Fristen in den Wagons einfach überschrieben werden können. Schliesslich noch ein Gedanke: Welchen Effekt haben die Kriterien auf ganz neu angelegte Kontakte. Gibt es da einen Pfad, bei dem ein neuer Kontakt gleich wieder gelöscht würde? (z.B. ich erstelle einen Account für jemanden, der dann seine Kinder zu einem Lager anmelden will, entferne aber die Rolle gleich wieder da Verwalter keine Rollen brauchen.) Werden die "Kurzrollen" hier berücksichtigt (im Verlauf fehlen sie ja) oder braucht es evtl. noch ein Mindestalter für den Account? |
Merci für die Rückmeldung
Ja, das ist ein guter Punkt. Vielleicht muss die Erstellung des Accounts noch mit berücksichtigt werden, falls keine Rollen zu finden sind. Ev. ist das über den Rollen-Log aber auch abgedeckt. |
Meine Gedanken zur neuen Spezifikation (#2106 (comment))
|
@richardjubla merci für dein Feedback. Ich versuche mal, auf deine einzelnen Punkte einzugehen:
|
Vielen Dank @simfeld !
Korrekt. Ich habe überlegt ob und wie sowohl Profile mit Login wie auch Profile ohne Login gleich oder ähnlich erfasst werden könnten. Ich habe nicht an spezifische Unterscheide (für die Jubla) gedacht.
Ich behaupte: Die Datenschutz-Grundverordnung (DSGVO) der Europäischen Union, enthält Bestimmungen für die Benachrichtigung von Benutzern vor der Löschung ihrer Daten (inkl. der Möglichkeit seine Daten zu exportieren oder an einen anderen Ort zu transferieren. Zum Beispiel wenn ein Mensch von der Jubla zur Pfadi wechseln möchte :-)) . Beim rev DSG genügt eine Erwähnung in der Datenschutzerklärung.
Die Überlegungen zur Nachvollziehbarkeit sind hier: #2106 (comment) Eventuell würde ein Text im Sicherheitstab genügen oder hilfreich sein:
Ich sehe noch "Risiken" bei Rechnungen, bei denen die rechtliche Aufbewahrung oder Nachverfolgbarkeit doch bei 5 Jahren (rechtlich) liegen sollte. Ein offene Rechnung solle nicht "auf einmal" ihren Debitor/Schuldner verlieren. Eigentlich müsste es doch mit vertretbarem Aufwand möglich sein, bei erfüllten Kriterien den Zeitpunkt der Löschung gleich zu berechnen und an ausgewählten Orten (Profil, Export, etc.) anzuzeigen. Es würde auch Supportfälle minimieren in denen die Frist/Kriterien nicht klar oder falsch interpretiert werden.
Denkt an eueren Prozess für die Datenauskunft. Hier wird der Mensch eine Anfrage mit Name, Vorname, Geburtsdatum und Wohnort (gemäss ID/Pass/FKZ) stellen. Minimierte Profile könnten dann nicht mehr mit der genügenden Genauigkeit identifiziert werden. Ein Hans Muster mit dem Geburtsjahr 1988 würde evtl. mehrere Profile triggern. Ein minimiertes Profil könnte auch der rechtlichen Nachweispflicht für die Eindeutigkeit nicht mehr standhalten. Gedanklich (keine Meinung!) macht für mich deshalb die Minimierung nur dann Sinn, wenn ein "gelöschtes" Profil noch einen statistische Aufgabe haben soll. Man erfährt auf keinen Fall mehr wer dieser Mensch war, lediglich an welchen Events/Statistiken das Anonyme Profil gezählt wurde.
Erschein mir schlüssig und korrekt. |
@richardjubla Merci für deine Antworten, soweit verwertbar 😄 MinimierungIch verstehe deine Bedenken, aber ich sehe nach wie vor eine Berechtigung für Datenminimierung gegenüber Datenlöschung. Meine Gedanken dazu:
Löschung von Elternzugängen
Dies ist mein Verständnis der neuen Spezifikation. Nur hat halt die Regel 4 "Die Person verwaltet keine Accounts mehr (Elternzugang)" bei Kindern keinen Effekt, sondern nur bei Elternaccounts. Aber die generelle Logik sollte für alle Benutzeraccounts gelten. |
Kriterium 4 kann wohl ebenfalls nicht im Core gelöst werden. Der Elternzugang ist ein Youth Feature, entsprechend müsste meines Erachtens auch dies im Youth Wagon gelöst werden. |
Mir sind beim Durchlesen und Durchdenken für die technische Konzeption noch folgende Punkte aufgefallen:
Falls jemand zu diesen Annahmen noch Bedenken hat, gerne noch melden. Wenn ich nichts höre gehe ich davon aus, dass die Annahmen für den Anfang mal okay sind. |
Aus meiner Sicht ist der Zweck des Minimierens nicht die Person verschwinden zu lassen, sondern nur die nicht mehr benötigten und nicht mehr gepflegten Daten zu entfernen. Minimierte Personen sollten wie normale Kontakte mit vielen leeren Feldern behandelt werden:
Die Einträge im Log sind für uns nicht kritisch. Es ist beides ok, sowohl dass der Name weiterhin angezeigt wird, wie auch, dass er verschwindet (mit Präferenz zu ersterem). Wir zeigen aber ja sowieso nur die letzten 3 Monate an. |
Merci für die Antworten. Muss denn eine Person in dem Fall doch auch mehrmals minimiert werden können, wenn sie ja trotz Minimierung wieder aufgegriffen werden kann? In der Spezifikation steht eben "Markierte Profile werden nicht erneut minimiert." Wie können wir erkennen, dass eine minimierte Person inzwischen wieder "reaktiviert" wurde, einfach anhand dem Kriterium "hat keine Rolle (in einer Gruppe) in den letzten 18 Monaten"? Ich kann mir vorstellen, dass das auch pro Wagon definierbar sein soll, aber ich brauche für die technische Spezifikation wenigstens ein Anschauungsbeispiel solcher Kriterien, damit ich die korrekte Architektur wählen kann. |
In der Spezifikation steht doch auch "Die Markierung wird aufgehoben, wenn eine Person eine Rolle erhält (Gruppe oder Event)." Du erkennst eine reaktivierte Person also daran, dass sie keine Markierung hat... oder was verstehe ich falsch? |
Hier mein Vorschlag für die Umsetzung der Minimierung im PBS-Wagon. @simfeld Merci für dein Feedback! Es wird gelöscht:
Im Umkehrschluss wird folgendes beibehalten:
|
@ThomasEllenberger Aufteilung passt so, merci! |
Siehe neue Spezifikation: #2106 (comment)
Hier der ursprüngliche Text:
Auf Basis der Diskussion in #1299 und dem Issue hitobito/hitobito_pbs#273 möchten wir eine automatisierte Datenlöschung einrichten. Siehe auch #2105 für die manuelle Datenlöschung.Der Prozess wird angestossen, wenn kein Opt-In für eine Ehemaligengruppe erfolgt ist. Etwas spezifischer: Wenn 2 Monate nach dem Reminder-Mail aus hitobito/hitobito_pbs#273 weiterhin keine Rolle gesetzt ist, wird eine Löschung überprüft.Kriterien, die eine Löschung verhindern:Die Person hat eine Rolle (in einer Gruppe)Die Person hat eine Voranmeldung oder Anmeldung für Kurse, Lager oder Anlässe in der ZukunftDie Person hat in den letzten 10 Jahren an einem Kurs- oder Lager teilgenommen (Siehe auch PERSON: Datenlöschung #2105)Die Person hat sich im letzten halben Jahr eingeloggt@richardjubla @nchiapol Seht ihr hier Potential, dass ihr das auch einsetzen könntet? Oder ist das definitiv im PBS-Wagon?Tech-Spec
ToDo
minimized_at
aufPerson
hinzufügen, defaultnil
minimized_at
der Person aufnil
setzen und in die DB speichernPeopleCleanupJob
erstellenPeopleCleanupFinder
anlegen. Grundbedingungen:Group::DeletedPeople#deleted_for
umgesetzt werden, aber nicht auf eine Gruppe limitiert, und mitroles.deleted_at <=
statt=
, plus den Spezial-Case von gar keiner Rolle (ja, das ist möglich, z.B. wenn man sich für einen externen Anlass zu registrieren beginnt, aber nie abschliesst. Oder wenn eine Person neu erfasst wird, und dann innert kurzer Zeit die Rolle wieder gelöscht wird)nil
oderfalse
als Special Case behandeln. Hauptsache der Job findet standardmässig möglichst nie irgendwelche Personen welche je eine Rolle hattenevent_participations
für Events mit zukünftigem Datum (achtung, Events können mehrere Daten haben)current_sign_in_at
istnil
oder älter als X Monatenil
oderfalse
als Special Case behandeln. Hauptsache der Job findet standardmässig möglichst nie irgendwelche Personen welche sich je eingeloggt haben.people_manageds
(Kinder welche von der gefundenen Person via Elternzugang verwaltet werden)find_in_batches
, da die Liste potenziell sehr lang sein kann, wenn das Feature neu eingeführt oder die Grundbedingungen / Settings geändert werden. Für jede gefundene Person:event_participation
in einem beliebigen Event hat, welcher einevent_date
hat das weniger als X Jahre in der Vergangenheit liegt:minimized_at
nichtnil
ist, Abbruch (Person ganz überspringen / ignorieren, nicht auf das andere Lösch-Verhalten zurückfallen)PersonMinimizer
anlegen.perform
) enthält im Core keinerlei Logik / Verhalten, ist also ein no-op. Die Idee ist, dass diese Methode in Wagons überschrieben werden kann, um das Verbands-spezifische Minimierungs-Verhalten zu implementieren.PersonMinimizer
s der Timestampminimized_at
aufNOW
gesetztevent_participation
hat, kommt die Datenlöschung zum Zuge.PersonDestroyer
anlegen, welche im Core die Person mitdestroy
löscht, aber im Wagon überschreibbar ist.family_members
), welche nach der Löschung nur noch ein Mitglied haben, auflösenhousehold_key
auf Tabellepeople
), welche nach der Löschung nur noch ein Mitglied haben, auflösenperson_id
der Rechnung aufnil
gesetzt werden, weil die Personalien eh schon bei der Rechnungsstellung auf die Rechnung kopiert werden.The text was updated successfully, but these errors were encountered: