Automatisches hinzufügen zur Ehemaligengruppe

[ThomasEllenberger]

Die Jubla hat seit 2017 Ehemaligengruppen und eine Automatik dass Personen welche die letzte Rolle verlieren automatisch in eine Ehemaligengruppe aufgenommen werden, und dass an Personen welche in die Ehemaligengruppe aufgenommen werden automatisch ein Email versendet wird.

Dieses Feature scheint bereits seit längerem nicht mehr wie gewünscht zu funktionieren.

Ziel dieses Tickets ist es, das genaue gewünschte Verhalten bei Ehemaligen bei der Jubla zu erruieren und festzuhalten was noch wie funktioniert und wo Arbeiten notwendig sind.

Durch die beiden Issues #371 sowie #372 wurde das Feature ursprünglich umgesetzt.
Gemäss einem Help-Ticket vom 17.05.2023 funktioniert das Feature nicht mehr.

Ursprüngliche Funktionalität:

Gemäss den urspünglichen Issues #371 sowie #372 sollte das Feature wie folgt funktionieren:

• Die Jubla hat in jeder Schar automatisch eine Gruppe "Ehemalige"
• Wird bei einer Person (welche nicht in einer Kindergruppe war (Ausnahme: älter als 15 Jahre)) die letzte aktive Rolle gelöscht, wird sie automatisch in der Gruppe Ehemalige als Mitglied hinzugefügt.
  • Diese Prüfung schaut nur die aktuelle Ebene an. Rollen in anderen Ebenen haben keinen Einfluss
• Erhält eine Person durch das Beenden der Rolle automatisch eine neue Rolle in einer Ehemaligengruppe wird am Folgetag eine Email ausgelöst.
  • Dies passiert nicht bei einem Import, oder dem manuellen hinzufügen der Rolle in der Ehemaligengruppe.

Bedingungen für das versenden der Email:

• Die letzte aktive Rolle der Person in dieser Gruppe und Ebene wird gelöscht
• Die gelöschte Rolle war mindestens 7 Tage alt (sonst wird die Rolle bei der Löschung als "Versehen" angesehen und komplett gelöscht ohne eine Ehemaligenrolle zu erstellen oder Mails zu versenden)
• Die gelöschte Rolle war nicht in einer Kindergruppe
  • Falls die Rolle doch in einer Kindergruppe war, muss die Person mindestens 15 Jahre alt sein. Ist kein Geburtsdatum gesetzt, wird auch keine Ehemaligen-Rolle erstellt und kein Mail versendet
• Es hat vorher noch keine Ehemaligenrolle in dieser Ebene existiert
• Die Ehemaligenrolle kann erfolgreich gespeichert werden
• Die Person hat eine Haupt-E-Mailadresse
• 1 Tag ist seit dem Löschen der Aktivrolle vergangen, und die Ehemaligenrolle existiert immer noch
• Die Gruppe der letzten Rolle war keine Schar - in Scharen wird unter denselben Bedingungen ein anderer E-Mail-Text versendet, den du ebenfalls einstellen können müsstest

Useacases

@richardjubla: Welche konkreten Usecases gibt es bei euch für Ehemalige? Und was wären die korrekten, gewollten Abläufe bei diesen Usecases?

Weitere Inputs:

Bei Personen welche via "Bis Datum" in der Zukunft gelöscht wurden, könnte #1748 ein mögliches Problem sein.

[nchiapol]

Wenn das bei der Jubla nun auch noch einmal angefasst werden muss, scheint mir noch wahrscheinlicher, dass wir uns auf eine Grundfunktionalität einigen könnten, die im Core umgesetzt werden kann (vgl. auch meinen Kommentar zu hitobito/hitobito_pbs#273).

Wie immer mit dem Vorteil, dass wir alle davon profitieren und dass wir die Komplexität des ganzen Systems kleiner halten können.

[ThomasEllenberger]

Eine Implementation einer automatisierten Bearbeitung ehemaliger Personen im Core scheint mir eher unwahrscheinlich. Hier sind die Bedürfnisse (schon bei den Jugendvereinen, und erst recht bei anderen Kunden) sehr unterschiedlich. Auch wird es ein rechtliches Thema mit dem Aufbewahren von Daten von ehemaligen Mitgliedern.

Eine kurze interne Diskusion hat ergeben, dass bei der Erarbeitung der Lösung der Pfadi, die Lösung der Jubla angeschaut und als für sie nicht zielführend angesehen wurde, da die Bedürfnisse zu fest abweichen. Auch ist eine Auslösung des Jubla Features aus dem Jubla Wagon und integration in einen anderen Wagen vermutlich nicht ganz trivial, da es an diversen Punkten ansetzt und nicht so einfach isolierbar ist.

[nchiapol]

Danke für die Rückmeldung. Ich hatte primär an das Auslösen eines automatischen Mails beim Verlust der letzten Rolle einer Ebene gedacht. Diese Funktion scheint bei Pfadi und Jubla ziemlich ähnlich. Dass es danach je nach Verband sehr unterschiedlich weitergeht sehe ich auch so.

[richardjubla]

Danke für die Issue, @ThomasEllenberger

Es basiert auf meinem Ticket vom 17.5.22 und 16.5.23. Die Absicht ist und war, herauszufinden wie und ob überhaupt das Ereignis "Ehemalige: Benachrichtigung" (E-Mail) ausgelöst wird.
Eine endgültige Aussage ist immer noch offen oder ungeklärt. Ich gehe aber mittlerweile "einfach" davon aus, dass seit über einem Jahr Menschen welche alle ihre aktiven Rollen entfernt bekommen oder verlieren (per Datum), nicht mehr wie beabsichtigt per E-Mail darüber benachrichtigt werden.

Das Thema Ehemaligenwesen wird/kann aktuell (Q2 April-Juni) nicht weiterverfolgt oder bearbeitet werden, sollte aber nach Möglichkeit im Q3 oder diesem Jahr wieder Aufmerksamkeit erhalten. Wir möchten uns sicher bis ende Juni zum Thema SilverScouts und Datenlöschung (PERSON: Datenlöschung #2105) äussern.

Die Fachgruppe Datenbank hatte die Erweiterung damals (14.3.2018) wie folgt umschrieben: https://mitglieder.jubla.ch/mitglieder/blog/2018/jubladb-erweiterung-fuer-ehemalige/
jubla.db-Erweiterung für Ehemalige - Jungwacht Blauring Schweiz.pdf

Nach meiner Interpretation hat die Ehemaligen-Erweiterung zum Ziel, eine verwaltbare Struktur zur Ebene "ohne Rollen" zu etablieren. Das Ehemaligen-Wesen kann sich organisatorisch wie auch rechtlich weiterhin um seine Mitglieder/Kontakte kümmern. Entweder weiter auf Vereins-Ebene oder durch einen übertritt in andere (übergeordnete) Strukturen (Kantonalverband/Verband). Wichtig ist, dass ein Ehemaliges-Profil organisatorisch/rechtlich weiterhin Mitglied bleibt oder rechtlich bewirtschaftet werden darf.

Der MVP wäre:

• Ein Profil welches keine aktiven Rollen in einer Ebene/Gruppe mehr hat (Austritt, Inaktiv, Mutation, etc.) wird automatisch (gemäss Regeln) der Ehemaligen-Gruppe zugeteilt.
• Das Profil wir per E-Mail über den Stauts und die möglichen Optionen informiert (E-Mail)
• Das Profil kann aktiv wählen (opt in / opt out) welche Ebenen (lokal. regional, kantonal, national) auf die eigenen Daten zugreifen kann (kontaktiert werden, Nutzung der Daten für Kommunikation)
• (Optional) Das Profil "rutscht" in den Ehemaligen-Gruppen nach oben, falls der jeweils übergeordnete Verein/Verband die (rechtliche) Zuständigkeit für das Profil übernehmen will/muss. (Der Kantonalverband muss sich um Ehemalige Mitglieder kümmern, falls ein Mitglied nicht mehr in der lokalen Schar ehemalig ist oder sein will/kann.)

Notwendige Konfigurierbarkeit für mögliche Community-Lösung:

• Regeln für Zuteilung "Ehemalig" oder "ohne Rollen" / bestehende Regeln verständlich/editierbar machen
• Editierbarkeit des Ereignis "Ehemalige: Benachrichtigung" (E-Mail) / bereits umgesetzt
• (optional) Editierbarkeit und Regeln für das Ereignis "Silverscouts: Automatismus / Opt-in 273)
• Festlegen der Berechtigung und Sichtbarkeit der Profile in der Ehemaligen-Gruppe (Falls rechtlich/organisatorisch gewünscht oder notwendig)
• Festlegen der Berechtigungen für Profile, welche Ehemalige sehen/bearbeiten dürfen (Optional: ob Ehemalige ihr Log-in zu eignem Profil verliehren)
• Informationen und Optionen der Kontaktfreigabe editierbar machen (optin/optout Kontakt mit Einbezug Feature PERSON: Einverständnis Datenschutzerklärung (DSE) einholen #1881)
• Der Ehemaligen-Status hat (rechtlich) eine Archiv- und Verwaltungs-Funktion und verhindert, dass ein Profil gelöscht werden möchte/muss. Für eine Community-Lösung würde ich den Status "Ehemalig" an eine automatische Löschung in maximal 10 Jahren Inaktivität binden. (oder die generellen Regeln für "recht auf vergessen")

[ThomasEllenberger]

Habe dies nun auch noch ausgiebig getestet und komme zum Schluss dass die ursprünglichen Funktionen alle noch funktionieren wie spezifiziert und nur der Mailversand nicht ausgelöst wird. Damit werden aktuell auch alle Funktionen des von @richardjubla erwähnten MVP erfüllt, ausser dem optionalen Punkt und dem Mailversand der aktuell buggy ist.

Einer Lösung im Core sehe ich noch immer kritisch entgegen, da soweit ich das neue DSG im Kopf habe, rechtlich die Daten nach Austritt nicht länger als 6 Monate gespeichert bleiben dürfen.

Vermutlich habe ich mit dem Issue hier etwas überreagiert, da mir der Automatismus der Jubla unbekannt war und dies hätte nur ein Bugissue sein müssen. Wollt ihr @richardjubla und @nchiapol dies weiter als Konzeptissue verwenden? Dann würde ich ein neues Bugissue eröffnen, sonnst wandle ich dieses in ein Bugissue um.

Testcases:

Gruppe: Jubla Schweiz / BE / QA / Test Ehemalige

• Sämtliche Personen welche ihr letzte Rolle verlieren werden korrekt in die Ehemaligengruppe verschoben. Ausnahme ist wenn die letzte Rolle eine "Versandadresse" war. Diese wird in die Gruppe "Ohne Rollen" verschoben.
• Auch die Rolle "Kind" wird korrekt verschoben (über 15 jahre alt = Ehemalige / unter 15 Jahre alt verschwindet komplett (landet auch nicht in ohne Rollen))
• Emails wurden in meinem Test in keinem Fall versendet!
• Interessant: Auch Mails bei der Imitation von Personen wurden nicht versendet. (Weiter habe ich nur noch Mailabos getestet, diese werden korrekt versendet.)

[richardjubla]

Einer Lösung im Core sehe ich noch immer kritisch entgegen, da soweit ich das neue DSG im Kopf habe, rechtlich die Daten nach Austritt nicht länger als 6 Monate gespeichert bleiben dürfen.

Diese Rechte ergeben sich aus den Bearbeitungsgrundsätzen nach Art. 6 revDSG:

• Personendaten werden vernichtet oder anonymisiert, sobald sie zum Zweck der Bearbeitung nicht mehr erforderlich sind (Abs. 4)
• Wer Personendaten bearbeitet, muss sich über deren Richtigkeit vergewissern. Sie oder er muss alle angemessenen Massnahmen treffen, damit die Daten berichtigt, gelöscht oder vernichtet werden, die im Hinblick auf den Zweck ihrer Beschaffung oder Bearbeitung unrichtig oder unvollständig sind (Abs. 5)

Ein Verein sollte demnach nach seinen Bearbeitungsgrundsätzen Daten löschen oder diese gemäss seiner Hitobito-Funktionen/Einstellungen an seine Mitglieder/Profile kommunizieren. Je nach Argumentation und Bearbeitungsgrundsätzen ist aber auch eine Speicherung für die Erfüllung von Pflichten (Nachweis Ausbildungen, Abrechnungen, Archiv, etc.) begründbar oder notwendig.

Diese Issue ist aus meiner Sicht kein Konzept. Profile ohne aktive Rollen sind aber sicher zu beachten. Ich habe bei der Löschung daran gedacht: #2106 (comment)

[ThomasEllenberger]

Zur besseren Übersicht wurde ein neues Bugissue eröffnet: #2121