PERSON: Automatisierte Datenlöschung

[Michael-Schaer]

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 Zukunft
• Die 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

• Umsetzung im Core, aber per default "ausgeschaltet" bzw. Defaults so gewählt dass es möglichst keinen Einfluss hat. Spezifika von Fristen und Vorgehen bei Minimierung werden dann in jedem Wagon einzeln definiert.
• Abgrenzung: Folgende in der Diskussion erwähnten Features werden vorerst noch ausgeklammert, bzw. können in Wagons ergänzt werden:
  • Nutzen und erweitern der Spalte "Login" - der letzte Login verzögert zwar die Löschung / Minimierung, aber dieses Datum ist im UI bisher nirgends sichtbar
  • Im Tab "Sicherheit" einsehbar und einzelne Stati und Abhängigkeiten werden dort erklärt - wurde in der Spezifikation der PBS bisher nicht aufgenommen, müsste also ev. durch die Jubla ergänzt werden. Das Sicherheits-Tab als Ort der nachträglichen Nachvollziehbarkeit oder Nachvollziehbarkeit kurz vor der Löschung ist ein Denkfehler - zu diesen Zeitpunkten kann niemand mehr auf das Sicherheits-Tab zugreifen ausser die Person selbst, und wenn sie es selbst macht, muss sie sich dafür einloggen und verzögert somit automatisch die Löschung.
  • Erklärender, generischer Text im Sicherheitstab - wurde in der Spezifikation der PBS bisher nicht aufgenommen, müsste also ev. durch die Jubla ergänzt werden
  • Zeitpunkt der Löschung im Voraus berechnen und an ausgewählten Orten anzeigen - ähnlich wie beim Sicherheits-Tab: diese Information wäre, sobald sie verfügbar wäre, für praktisch niemanden mehr zugänglich. Für Personen mit aktiver Rolle gibt es z.B. schlicht kein vorausgesagtes Löschdatum, weil aktive Rollen meist noch kein Enddatum haben.
  • Status "wird gelöscht" der für 60 Tage angezeigt wird - wurde in der Spezifikation der PBS bisher nicht aufgenommen, müsste also ev. durch die Jubla ergänzt werden
  • Status "inaktiv" - wurde in der Spezifikation der PBS bisher nicht aufgenommen, müsste also ev. durch die Jubla ergänzt werden
  • Benachrichtigungen an zu löschende Person und/oder Verantwortliche - laut Spezifikation gibt es zum Löschzeitpunkt schon länger keine Verantwortlichen mehr (je nach Einstellung natürlich). Benachrichtigung an die zu löschende Person selber wurde in der Diskussion später wieder verworfen, weil es im schweizer DSG nicht vorausgesetzt wird.
  • Nach der Umsetzung sollen alte Accounts nicht sofort oder massenhaft gelöscht werden - wegen der sehr restriktiven Standards im Core werden nur Personen die keine Rolle (auch keine beendete) haben und sich gar nie eingeloggt haben gelöscht. Wenn Wagons diese Settings anpassen, sind sie selber verantwortlich, die Regeln so zu setzen dass keine ungewollt massenhafte Löschung eintritt. Auf einer hohen Flugebene ist es aber eigentlich korrekt, dass bei Einführung dieses Features erst mal sehr viele Datenleichen gelöscht werden, welche gemäss dem neuen DSG schon viel zu lange unnötig herumliegen.
  • Erstellungsdatum des Accounts bzw. Kurz-Rollen berücksichtigen - dazu wurde nichts näheres spezifiziert. Personen die gar keine Rolle und gar keine Anlassteilnahme haben (auch keine vergangenen) und sich nie eingeloggt haben, werden gemäss aktueller Spezifikation beim nächsten Löschungs-Lauf gelöscht.
  • Weitere Grundbedingung "Person wurde in den letzten 24 Monaten nicht bearbeitet" oder "Person hat keine Log-Einträge in den letzten 24 Monaten" - diese Bedingung hatte Denkfehler drin: Damit eine Person bearbeitet werden kann bzw. einen Logeintrag bekommen kann, muss jemand Schreibrechte auf die Person haben, was wiederum eine Rolle bedingt. Diese weitere Grundbedingung könnte also höchstens einen Unterschied machen, wenn jemand die Person bearbeitet, und ihr dann auf der letzten Rolle das Enddatum auf vor 2 Jahren setzt.
  • Risiken bei Rechnungen, bei denen die rechtliche Aufbewahrung oder Nachverfolgbarkeit bei X Jahren liegen sollte - wurde in der Spezifikation der PBS bisher nicht aufgenommen, müsste also ev. durch die Jubla ergänzt werden
  • Terminologie: "Minimierung" soll auch als eine Art der "Löschung" bezeichnet werden - im UI wird bisher nirgends etwas von der Löschung oder Minimierung angezeigt. Die Terminologie ist komplett den Verbänden überlassen, wenn sie dieses neue Feature ihren Mitgliedern erklären.
• Notizen für Wagons, welche eine Minimierung implementieren:
  • Daran denken, das Log (PaperTrail) sowie alle anderen has_many oder has_one Beziehungen der minimierten Person aufzuräumen.
  • Falls die Haupt-E-Mail nicht entfernt wird, muss geklärt werden, ob sich minimierte Personen weiterhin einloggen dürfen.

ToDo

• DB-Migration: Neue Timestamp-Spalte minimized_at auf Person hinzufügen, default nil
• Beim Erstellen einer Rolle oder Participation, minimized_at der Person auf nil setzen und in die DB speichern
• Täglich laufenden scheduled Delayed::Job namens PeopleCleanupJob erstellen
• Job sucht alle Personen, auf die folgende Grundbedingungen zutreffen. Dafür eine Domainklasse PeopleCleanupFinder anlegen. Grundbedingungen:
  • Person hatte nie eine Rolle, oder letzte Rolle ist seit mehr als X Monaten beendet. Achtung: Auch archivierte und soft deletete Rollen miteinbeziehen! Logik kann ähnlich wie Group::DeletedPeople#deleted_for umgesetzt werden, aber nicht auf eine Gruppe limitiert, und mit roles.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)
    • X Monate ist in settings.yml definierbar
    • Standardwert sehr hoch wählen, oder -1 oder nil oder false als Special Case behandeln. Hauptsache der Job findet standardmässig möglichst nie irgendwelche Personen welche je eine Rolle hatten
  • Es existieren keine event_participations für Events mit zukünftigem Datum (achtung, Events können mehrere Daten haben)
  • current_sign_in_at ist nil oder älter als X Monate
    • X Monate ist in settings.yml definierbar
    • Standardwert sehr hoch wählen, oder -1 oder nil oder false als Special Case behandeln. Hauptsache der Job findet standardmässig möglichst nie irgendwelche Personen welche sich je eingeloggt haben.
  • Bestehende Grundbedingungen sollen in Wagons überschreibbar sein, und neue Grundbedingungen sollen in Wagons hinzugefügt werden können.
  • Im Youth Wagon eine zusätzliche Grundbedingung hinzufügen: Es existieren keine people_manageds (Kinder welche von der gefundenen Person via Elternzugang verwaltet werden)
• Über alle gefundenen Personen loopen, am besten mit 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:
  • Falls die Person eine event_participation in einem beliebigen Event hat, welcher ein event_date hat das weniger als X Jahre in der Vergangenheit liegt:
    • (Wie oben, X Jahre in settings.yml definierbar, Standardwert so dass möglichst wenige Personen gefunden werden)
    • Diese Zusatz-Bedingung (Participations in beliebigem Event in den letzten X Jahren) in Wagons überschrieben und ergänzt werden können.
    • Falls auf der Person minimized_at nicht nil ist, Abbruch (Person ganz überspringen / ignorieren, nicht auf das andere Lösch-Verhalten zurückfallen)
    • Person wird minimiert. Dazu eine Domainklasse PersonMinimizer anlegen.
      • Haupt-Methode (z.B. 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.
      • Trotzdem wird beim Aufruf des PersonMinimizers der Timestamp minimized_at auf NOW gesetzt
  • Falls die Person keine solche event_participation hat, kommt die Datenlöschung zum Zuge.
    • Auch dafür eine neue Domain-Klasse PersonDestroyer anlegen, welche im Core die Person mit destroy löscht, aber im Wagon überschreibbar ist.
    • Families (via Tabelle family_members), welche nach der Löschung nur noch ein Mitglied haben, auflösen
    • Haushalte (via Spalte household_key auf Tabelle people), welche nach der Löschung nur noch ein Mitglied haben, auflösen
    • Rechnungen die der gelöschten Person gestellt wurden sollen zu "externen" Rechnungen konvertiert werden. Vermutlich muss dafür einfach die person_id der Rechnung auf nil gesetzt werden, weil die Personalien eh schon bei der Rechnungsstellung auf die Rechnung kopiert werden.
• Im PBS-Wagon die Settings folgendermassen anpassen:
  • Minimales Alter der letzten beendeten Rolle: 18 Monate
  • Minimales Alter des letzten Logins: 24 Monate
  • Minimales Alter des letzten besuchten Events: 10 Jahre
• Specs schreiben
• Manuell durchtesten
• Folgendes Szenario testen: Eine Person A bearbeitet eine andere Person B, und so entsteht bei B ein Log-Eintrag der besagt dass A etwas geändert hat. Später wird Person A durch den hier implementierten Prozess gelöscht. Der Log-Eintrag auf Person B sollte weiterhin sichtbar sein, aber der Name von Person A sollte nicht mehr ersichtlich sein.
• CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

[nchiapol]

Aus meiner Sicht darf das gerne in den Core - einfach die "10 Jahre"-Frist bitte konfigurierbar machen (in wagon/config/settings.yml). Damit liesse sich das dann sowohl problemlos deaktivieren wie auch verkürzen. (Falls man die Aufbewahrung ausserhalb der DB lösen will.)

[richardjubla]

Hier meine Gedanken zu einem MVP auf core/youth-Ebene:
(Achtung: hat sicher noch logische Fehler drin! Die genannten Kriterien für Rollen, Events und Login sind aber abgedeckt)

Voraussetzungen:

• Kann nicht auf Regeln oder individuelle Einstellungen einzelner Wagon eingehen
• Nutzen und erweitert der Spalte "Login"
• Ist im Tab "Sicherheit" einsehbar und müsste die jeweiligen Stati und Abhängigkeiten erklären.
  

Status:
Neuer Status für Spalte "Login": "inaktiv" und "wird gelöscht"

Config:
Timer (Anzahl Tage) für ohne Login - 370 Tage
Timer (Anzahl Tage) seit letztem Log-Eintrag - 600 Tage
Timer (Anzahl Tage) seit inaktiv - 365 Tage
Anzahl Tage von "wird gelöscht" bis Datensatz wird wirklich gelöscht - 60 Tage
Option: Bei Status "inaktiv" Passwort zurücksetzten oder Login deaktivieren - PW zurücksetzten
Option: Trigger an Profil und/oder Verantwortliche auslösen - JA
Option: Profil ohne aktive Rollen wird nach 60 Tagen "inaktiv" - NEIN

Trigger/Ereignis (per E-Mail):

• Warnung: Keine aktiven Rollen mehr (Profil) / Optional:
• Warnung: Account inaktiv (Profil & Kontaktperson und/oder Haupt-E-Mail der Ebene / Haupt-E-Mail des Event)
• Warnung: Account wird gelöscht (Profil & Kontaktperson und/oder Haupt-E-Mail der Ebene / Haupt-E-Mail des Event)

Ablauf / User-Story:
Ein Profil bekommt Sanduhr/Timer welcher sich auf die automatisierte Datenlöschung auswirkt. Dieser Timer sollte für den User selbst aber insbesondere auch für die Verwalter (Vorstand, Elternzugang, Adressverwaltung, Rechnungssteller/Kassier) nachvollziehbar sein. Schliesslich hat eine solche Löschung auch Auswirkungen auf den Vereinsalltag, Rechtliche Konsequenzen oder tangiert andere Verbindlichkeiten.

So wird das Profil (und die Verwalter) nach Ablauf der Timer Login und Log-Eintrag auf "inaktiv" markiert und per Warnung darüber informiert. Ein inaktives Profil kann durch zurücksetzen der Timer wie zum Beispiel einer Anmeldung ins Profil, bearbeiten des Profils oder einer Aktivität (erzeugt Log-Eintrag) wieder aktiviert werden. Ein aktives Vereinsmitglied (selbst ein durch Eltern verwaltetes) sollte eigentlich nie inaktiv werden.
Wird dem Profil seine letzte aktive Rolle entfernt, wird es über diesen Umstand informiert und je nach Konfiguration (Rechtslage / individuell je nach Verband) ebenfalls auf inaktiv gesetzt.
Inaktive Profile werden nach dem Ablauf der "inaktiv"-Zeit ein letztes Mal gewarnt und danach automatisch gelöscht. Auch hier kann das Profil oder die Verwalter eingreifen und eine automatische Löschung verhindern oder darauf reagieren (von wird gelöscht zu aktiv, inaktiv wenn ohne Rolle).

(Mit Umsetzung des Features müssten alle Timer neu gesetzt werden, damit alte Accounts nicht sofort oder massenhaft gelöscht würden)

[Michael-Schaer]

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:

1. Die Person hat keine Rolle (in einer Gruppe) in den letzten 18 Monaten
2. Die Person hat keine Voranmeldung oder Anmeldung für Events in der Zukunft
3. Die Person hat sich in den letzten 24 Monaten nicht eingeloggt
4. Die Person verwaltet keine Accounts mehr (Elternzugang)
5. Die Person hat in den letzten 10 Jahren weder an einem Kurs noch an einem Lager teilgenommen

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.

@simfeld @nchiapol @richardjubla @betsim

[nchiapol]

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?

[Michael-Schaer]

Merci für die Rückmeldung

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?

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.

[richardjubla]

Meine Gedanken zur neuen Spezifikation (#2106 (comment))

• Ich würde das Kriterium 3 (24 Monaten nicht eingeloggt) abändern auf 24Mt. ohne Login oder Log-Aktualisierung. Damit werden auch Menschen ohne Login erfasst, die ohne Login durch eine Adressverwaltung bewirtschaftet/erstellt wurden. Hat also ein Verein Mitglieder in der Datenbank (ohne Login) welche ohne Rollen und ohne Aktualisierung herumliegen, sollen diese doch ebenfalls einbezogen werden.
• Warnung: Mir fehlt eine Warnung und oder Nachvollziehbarkeit dieser automatisierten Löschung. Ein automatisch verschwundener oder anonymisierter Kontakt könnte doch recht Verwirrung oder Probleme verursachen. Eine Nachvollziehbarkeit dieses Ablaufs im Profil-Tab Sicherheit halte ich für "eine wichtige Idee".
• Die "Minimierung" ist nicht spezifiziert. Wenn sie jegliche eindeutige Zuordnung entfernt (Mail, Name, Verwaltung, IP, AHV, Strasse, etc.). Ist dies defacto eine Löschung (nach DSG) mit dem Vorteil, dass Statistiken wie Events/Bestandesmeldungen vorhanden bleiben. ( Mir macht dies gedanklich Probleme, wenn dies vermischt wird )
• Das Kriterium 4 (Person verwaltet keine Accounts mehr), führt dazu, dass diese Profile sozusagen zuerst ihre Kinder gelöscht/minimiert erhalten und erst dann selber von den Kriterien erfasst werden. Ich vermute, dass ein Elternzugang bei welchem das (letzte) Kind geböscht wird, wohl mit grosser Wahrscheinlichkeit gleich ebenfalls von den Kriterien erfasst wird. In Kombination mit Kriterium 5 werden Elternzugänge aus meiner Sicht zu spät oder nicht optimal von den Kriterien erfasst.

[simfeld]

@richardjubla merci für dein Feedback. Ich versuche mal, auf deine einzelnen Punkte einzugehen:

1. Kriterium 3:
   • Die Grundidee an der von @Michael-Schaer und mir vorgeschlagenen neuen Spezifikationen ist, dass der Core eine Basisimplementierung bietet, die einerseits konfigurativ abgeschalten und andererseits in Kunden-Wagons angepasst werden kann (wie überall in hitobito). Wie beschrieben sind Regeln 1 - 4 aus unserer Sicht generisch genug, um als Basisimplementierung im Core zu dienen. Möchte nun die Jubla das Verhalten ändern, kann im entsprechenden Wagon eine zusätzliche Bedingung "keine Log-Aktualisierung innerhalb der letzten 24 Monate" definiert werden, welche die Regeln für die Auslösung von Löschung oder Minimierung verschärft.
   • Darüber hinaus kann ich mir gut vorstellen, die von dir vorgeschlagene Bedingung als zusätzliche Regel in den Core aufzunehmen. Ich würde sie jedoch umformulieren: Eine Log-Aktualisierung bedingt meiner Ansicht nach ein Update des Personen-Eintrags durch eine andere Person mit Schreibrechten (sonst gibt es keinen Grund, das Log zu erweitern). Somit könnten man sagen "Person wurde in den letzten 24 Monaten nicht bearbeitet". Zusammen mit der bestehenden Regel 3 würde dies dein gewünschtes Verhalten ergeben, richtig?
2. Warnung:
   • Wir haben uns Gedanken über eine Benachrichtigung (Email) des Benutzers über eine bevorstehende Löschung gemacht. Hier ist Vorsicht geboten, weil nach Release dieses Features werden sehr wahrscheinlich in einem kurzen Zeitraum einige Tausend Nutzerkonten gelöscht aus den letzten 10 Jahren, was bei den betroffenen zu mehr Verwirrung als Klarheit führen könnte. Wir waren uns auch nicht sicher, ob bei einer Datenlöschung nach DSG eine solche Benachrichtigung gefordert wird. Weisst du dazu mehr?
   • Wie stellst du dir die Nachvollziehbarkeit des Prozesses im Sicherheitstab vor? Zum Zeitpunkt der Löschung gibt es ja nichts mehr nachzuvollziehen weil der Benutzer dann nicht mehr existiert. Es müsste also in einem definierten Zeitfenster davor über die bevorstehende Löschung informiert werden?
3. Spezifikation Minimierung:
   • Diese ist in einem gewissen Sinne absichtlich nicht spezifiziert, weil sie in den meisten Fällen wagon-abhängig sein wird. Gewisse Personenfelder existieren nur in spezifischen Wagons, also können sie auch nur dort überschrieben/zurückgesetzt werden.
   • Die Spezifikation ist der Teil hier: "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." sowie der Teil am Schluss "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." Das bedeutet, wenn das Feature auf deinem Deplyoment aktiv ist und du nichts weiter tust, passiert bei einer Minimierung erst einmal gar nichts. Du müsst das Minimierungsverhalten in deinem Wagon überschreiben und kannst dies so implementieren (lassen), wie es für deinen Verband/Verein stimmt. Ob du dabei jegliche eindeutige Zuordnung entfernst oder nicht, ist dir überlassen. Die PBS wird bei der Minimierung die J+S-Vorschriften zur Haltung von Lagerdaten berücksichtigen, was unter anderem bedingt, dass Name, Vorname, Geburtsjahr und AHV-Nummer nicht gelöscht werden dürfen (https://pfadi.swiss/media/files/df/merkblatt_-_datenauskunft_de.pdf).
4. Löschung von Elternzugängen:
   • "führt dazu, dass diese Profile sozusagen zuerst ihre Kinder gelöscht/minimiert erhalten und erst dann selber von den Kriterien erfasst werden" dies muss aus meiner Sicht das gewünschte Verhalten sein? Ein Elternzugang hat solange eine Berechtigung in hitobito wie in der Datenbank Kinder existieren, welche durch diesen Zugang verwaltet werden?
   • Du siehst es richtig, dass im Falle wo ein Kind ein Lager besucht hat, auch der Elternzugang erst 10 Jahre später gelöscht werden kann wenn Regel 4 und 5 gelten. Widerum gilt hier aber mein Kommentar zu Punkt 1, dass dieses Verhalten keineswegs im Core in Stein gemeisselt wird, sondern vielmehr wie in der neuen Spezifikation steht: "Das Kriterium 5 ist hingegen eher auf den Youth- oder sogar PBS-Wagon ausgerichtet".

[richardjubla]

Vielen Dank @simfeld !
Vielleicht sind meine weiteren Aussagen verwertbar....

@richardjubla merci für dein Feedback. Ich versuche mal, auf deine einzelnen Punkte einzugehen:

1. Kriterium 3:

   • Die Grundidee an der von @Michael-Schaer und mir vorgeschlagenen neuen Spezifikationen ist, dass der Core eine Basisimplementierung bietet, die einerseits konfigurativ abgeschalten und andererseits in Kunden-Wagons angepasst werden kann (wie überall in hitobito). Wie beschrieben sind Regeln 1 - 4 aus unserer Sicht generisch genug, um als Basisimplementierung im Core zu dienen. Möchte nun die Jubla das Verhalten ändern, kann im entsprechenden Wagon eine zusätzliche Bedingung "keine Log-Aktualisierung innerhalb der letzten 24 Monate" definiert werden, welche die Regeln für die Auslösung von Löschung oder Minimierung verschärft.
   • Darüber hinaus kann ich mir gut vorstellen, die von dir vorgeschlagene Bedingung als zusätzliche Regel in den Core aufzunehmen. Ich würde sie jedoch umformulieren: Eine Log-Aktualisierung bedingt meiner Ansicht nach ein Update des Personen-Eintrags durch eine andere Person mit Schreibrechten (sonst gibt es keinen Grund, das Log zu erweitern). Somit könnten man sagen "Person wurde in den letzten 24 Monaten nicht bearbeitet". Zusammen mit der bestehenden Regel 3 würde dies dein gewünschtes Verhalten ergeben, richtig?

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.
Ein bewirtschaftetes Profil wird (muss?) aber eine Rolle in einer Ebene/Gruppe haben. Ich habe hier wahrscheinlich falsch oder zu weit gedacht. Die Regel 3 würde demnach auf Profile ohne Login treffen, welche wegen fehlender Bewirtschaftung keiner Ebene/Gruppe mehr zugehören. Das stimmt so für mich.

2. Warnung:

   • Wir haben uns Gedanken über eine Benachrichtigung (Email) des Benutzers über eine bevorstehende Löschung gemacht. Hier ist Vorsicht geboten, weil nach Release dieses Features werden sehr wahrscheinlich in einem kurzen Zeitraum einige Tausend Nutzerkonten gelöscht aus den letzten 10 Jahren, was bei den betroffenen zu mehr Verwirrung als Klarheit führen könnte. Wir waren uns auch nicht sicher, ob bei einer Datenlöschung nach DSG eine solche Benachrichtigung gefordert wird. Weisst du dazu mehr?

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.
Ich finde deshalb, dass ein Profil (von uns) nicht über die baldige Löschung informiert werden muss.

• Wie stellst du dir die Nachvollziehbarkeit des Prozesses im Sicherheitstab vor? Zum Zeitpunkt der Löschung gibt es ja nichts mehr nachzuvollziehen weil der Benutzer dann nicht mehr existiert. Es müsste also in einem definierten Zeitfenster davor über die bevorstehende Löschung informiert werden?

Die Überlegungen zur Nachvollziehbarkeit sind hier: #2106 (comment)
Da wir uns hier aber über Profile ohne Rolle (Kriterium 1) reden, fehlt diesen Profilen auch eine (rechtlich) "verantwortliche Person" (Vereinsleitung, Adressverwaltung, Kassier) die Informiert werden müsste oder verantwortlich sein könnte.

Eventuell würde ein Text im Sicherheitstab genügen oder hilfreich sein:

Recht auf Vergessen - Wann wird mein Profil gelöscht?
Wir möchten sicherstellen, dass die in unserer Datenbank gespeicherten Informationen stets aktuell und relevant sind. Aus diesem Grund löschen wir inaktive Profile (gemäss unseren Datenschutzbestimmungen). Die Löschung erfolgt basierend auf bestimmten Kriterien, um sicherzustellen, dass nur nicht mehr benötigte Daten entfernt werden.
Die Kriterien für die Löschung inaktiver Profile sind wie folgt:
- Du hast innerhalb der letzten 18 Monate keine Rolle in einer Gruppe/Ebene
- Du bist weder für zukünftige Events vorangemeldet noch angemeldet (Event/Anlass/Kurs/Lager/etc.)
- Du hast dich in den letzten 24 Monaten nicht in dein Konto eingeloggt 
- Du verwaltest keine Profile (Elternzugang/Profilverwaltung).
- Du hast weder an einem Kurs noch an einem Lager in den letzten 10 Jahren teilgenommen.
Wenn dein Profil alle Bedingungen erfüllt, wird es automatisch gelöscht.

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.

3. Spezifikation Minimierung:

   • Diese ist in einem gewissen Sinne absichtlich nicht spezifiziert, weil sie in den meisten Fällen wagon-abhängig sein wird. Gewisse Personenfelder existieren nur in spezifischen Wagons, also können sie auch nur dort überschrieben/zurückgesetzt werden.
   • Die Spezifikation ist der Teil hier: "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." sowie der Teil am Schluss "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." Das bedeutet, wenn das Feature auf deinem Deplyoment aktiv ist und du nichts weiter tust, passiert bei einer Minimierung erst einmal gar nichts. Du müsst das Minimierungsverhalten in deinem Wagon überschreiben und kannst dies so implementieren (lassen), wie es für deinen Verband/Verein stimmt. Ob du dabei jegliche eindeutige Zuordnung entfernst oder nicht, ist dir überlassen. Die PBS wird bei der Minimierung die J+S-Vorschriften zur Haltung von Lagerdaten berücksichtigen, was unter anderem bedingt, dass Name, Vorname, Geburtsjahr und AHV-Nummer nicht gelöscht werden dürfen (https://pfadi.swiss/media/files/df/merkblatt_-_datenauskunft_de.pdf).

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.
(um eine komplette Anonymisierung zu ermöglichen, dürfte aus den Events keine Rückschlüsse auf einen eindeutigen Menschen möglich sein. Eindeutiges Profil aus Bewegungsdaten/Profilierung.)
Aus diesem Grund wäre für mich eine Minimierung immer gleichgesetzt mit der Löschung der/aller Profil-Informationen gleichzustellen da der Prozess nicht umgekehrt werden kann und durch die Minimierung ihre rechtliche Legitimierung verliert.
Bei einer Datenauskunft, gelten minimierte Profile als gelöscht und können nicht mehr einer Auskunft zugeordnet werden. (Ausnahme: Mit der Auskunft wird die AHV-Nr. angegeben und eindeutig in der Datenbank identifiziert)

4. Löschung von Elternzugängen:

   • "führt dazu, dass diese Profile sozusagen zuerst ihre Kinder gelöscht/minimiert erhalten und erst dann selber von den Kriterien erfasst werden" dies muss aus meiner Sicht das gewünschte Verhalten sein? Ein Elternzugang hat solange eine Berechtigung in hitobito wie in der Datenbank Kinder existieren, welche durch diesen Zugang verwaltet werden?
   • Du siehst es richtig, dass im Falle wo ein Kind ein Lager besucht hat, auch der Elternzugang erst 10 Jahre später gelöscht werden kann wenn Regel 4 und 5 gelten. Widerum gilt hier aber mein Kommentar zu Punkt 1, dass dieses Verhalten keineswegs im Core in Stein gemeisselt wird, sondern vielmehr wie in der neuen Spezifikation steht: "Das Kriterium 5 ist hingegen eher auf den Youth- oder sogar PBS-Wagon ausgerichtet".

Erschein mir schlüssig und korrekt.
Ein komplette Trennung von Löschung und Elternzugang wäre für mich auch eine Option: Die Regeln würde unabhängig für jedes Profil (ob Eltern/Kind) genau gleich gelten. Ein Verwaltungskonto würde dann nach den allgemeinen Regeln halt "einfach" sein Kind/Verwalter verlieren. Mir gefällt aber der Versuch, dies nach Möglichkeit abzufedern. Komplexer wird es wohl erst, wenn die Regeln für Löschung/Minimierung eher kurz für eine optimale Datensparsamkeit gesetzt werden und dann mögliche Nachforschungen/Nachweise oder rechtliche Pflichten beschneiden könnten.

[simfeld]

@richardjubla Merci für deine Antworten, soweit verwertbar 😄

Minimierung

Ich verstehe deine Bedenken, aber ich sehe nach wie vor eine Berechtigung für Datenminimierung gegenüber Datenlöschung. Meine Gedanken dazu:

• Die Sicherstellung der Einhaltung der gesetzlichen Vorgaben ist Aufgabe des Kunden/Verbandes und nicht der Software an sich. Die Software muss lediglich ermöglichen, dass die Vorgaben eingehalten werden könnnen.
• In diesem Sinne müssten wir "Name, Vorname, Geburtsdatum und Wohnort" bei einer Dateninminimierung erhalten. Für Felder wie "weitere Email", "Telefon", "Anrede" usw. haben wir aber wahrscheinlich keinen Verwendungszweck mehr und diese sollten somit gemäss dem Prinzip der Datensparsamkeit entfernt (= mit default überschrieben) werden. Da gemäss der obigen Spezifikation die Minimierungs-Implementierung im Core keinen Effekt hat (= alle Felder werden erhalten), ist das Default-Verhalten unproblematisch. Sobald ein Kunde eine Minimierung implementieren möchte welche über die Identitätsfunktion hinausgeht, müssen deine Überlegungen natürlich in Betracht gezogen werden.

Löschung von Elternzugängen

Die Regeln würde unabhängig für jedes Profil (ob Eltern/Kind) genau gleich gelten

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.

[ThomasEllenberger]

Der Prozess wird täglich angestossen, sofern mindestens die Kriterien 1-4 für eine Person erfüllt sind:

1. Die Person hat keine Rolle (in einer Gruppe) in den letzten 18 Monaten
2. Die Person hat keine Voranmeldung oder Anmeldung für Events in der Zukunft
3. Die Person hat sich in den letzten 24 Monaten nicht eingeloggt
4. Die Person verwaltet keine Accounts mehr (Elternzugang)
5. Die Person hat in den letzten 10 Jahren weder an einem Kurs noch an einem Lager teilgenommen

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.

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.