Silverscouts: Automatismus / Opt-in

[daniel-illi]

refs #235
requires #271

Automatismus / Opt-in

Wenn jemand in der MiData die letzte Rolle verliert, soll nach 3 Monaten eine Anfrage via Mail verschickt werden. Diese Anfrage soll konfigurierbar sein und folgende Textbausteine beinhalten:

• Silverscouts-Regionen
  • Alle Regionen anzeigen
  • Link führt zur Anmeldung für die jeweilige Region
• Ehemaligen-Gruppen von vergangenen Rollen
  • Von allen Rollen aus gesehen nach oben durchsuchen
  • Alle Gruppen vom Gruppentyp Ehemalige anzeigen
  • Link führt zur Anmeldung für die jeweilige Ehemaligen-Gruppe

Für den Automatismus gibt es diverse Kriterien:

1. Die letzte aktive Rolle der Person in dieser Gruppe und Ebene wurde gelöscht
2. Es sind 3 Monate verstrichen und keine aktive Rolle wurde hinzugefügt
3. Die gelöschte Rolle war mindestens 7 Tage alt (sonst wird die Rolle bei der Löschung als "Versehen" angesehen)
4. Die gelöschte Rolle war nicht in einer Kindergruppe (Biber, Wölfe, Pfadi, Pio, PTA)
5. Die gelöschte Rolle war nicht in einer Ehemaligengruppe
6. Falls die Rolle doch in einer Kindergruppe war, muss die Person mindestens 16 Jahre alt sein. Ist kein Geburtsdatum gesetzt, wird auch keine Ehemaligen-Rolle erstellt und kein Mail versendet
7. Es hat vorher noch keine Ehemaligenrolle in dieser Ebene existiert
8. Die Person hat eine Haupt-E-Mailadresse
9. Wenn die Person in irgendeiner Ehemaligen-Gruppe eine Rolle hat, sollte das Mail nicht verschickt werden.
10. Der Mailversand soll komplett (de)aktivierbar sein.

Wenn keine Rückmeldung eingeht, passiert erst mal nichts. Bei keiner Reaktion wird nach weiteren 3 Monaten ein Reminder (das gleiche Mail noch einmal) verschickt.

Tech-Spec

• Umsetzung im PBS-Wagon, weil viele Spezifika bei den Kriterien sowie bei der Ehemaligen-Gruppenstruktur
• Bei Löschen einer relevanten Rolle (nicht in Ehemaligengruppe) Jobs schedulen sofern die Rolle mindestens 7 Tage alt ist und die Person eine Email Adresse hat
  • mit run_at = 3.months.from_now für erstes Mail
  • mit run_at = 6.months.from_now für reminder Mail
• Täglicher Job der alle noch nicht angeschriebenen Rollen heraussucht
• Job prüft Bedingungen und versendet Mail falls alle erfüllt (siehe Kriterienliste oben)
• Job markiert alle verarbeiteten Rollen (auch diejenigen bei denen die Bedingungen nicht erfüllt waren) als abgearbeitet
• Dasselbe nochmals für den zweiten Reminder
• Zur Selbsteinschreibung: In den PRs Self inscription for groups with self registration enabled hitobito#2180 und Self registration links hitobito#2194 wurde ein Vorschlag für dieses Feature erarbeitet. Darin ist aktuell keine Lösung vorgesehen, um nur Selbsteinschreibung ohne Selbstregistrierung oder umgekehrt zu ermöglichen. Dies könnte aber in Zukunft noch nachgerüstet werden, falls dieses Bedürfnis mal aufkommt.

Offene Fragen

• Soll das Mail bereits alle Links für die Anmeldung in allen Silverscouts Regionen sowie die relevanten Ehemaligen Gruppen enthalten, oder implementieren wir eine Opt-In view mit den Links?

Antwort von @Michael-Schaer: via Selbstregistrierung lösen. Im Mail-Template könnten dann zwei Variablen {SiScRegion-Links} und {AlumniGroup-Links} verwendet werden. Die erste Variable enthält alle Links von SilverScouts-Regionen mit aktivierter Selbstregistrierung. Die zweite Variable enthält Links zu allen Ehemaligen-Gruppen im normalen MiData-Baum, die hierarchisch über der Person vorkommen und die Selbstregistrierung aktiviert haben.

ToDo

• Selbsteinschreibung als Grundlage für dieses Issue implementieren: Die 2 PRs Self inscription for groups with self registration enabled hitobito#2180 sowie Self registration links hitobito#2194 reviewen, finalisieren und mergen
  • Insbesondere noch Tests ergänzen, weil es unter Umständen ein berechtigungsrelevantes Thema ist, wenn man sich selber neue Rollen vergeben kann.
• Auf Role zwei neue Datumsfelder alumni_invitation_processed_at und alumni_reminder_processed_at einfügen
  • Default null
  • Via Migration bei allen bereits gelöschten Rollen (deleted_at < NOW()) in der Datenbank die beiden Datumsfelder mit dem Datum 1.1.1970 befüllen
• Täglich laufenden AlumniInvitationsJob erstellen
  • Job sucht alle Rollen mit deleted_at < 3.months.ago und deleted_at >= 6.months.ago und alumni_invitation_processed_at IS NULL und iteriert über diese (deckt bereits das fachliche Kriterium 3. (siehe oben) ab, weil wir für weniger als 7 Tage alte Rollen ein hard delete machen)
  • Bei jeder verarbeiteten Rolle, unabhängig von den nachfolgenden Bedingungen, das alumni_invitation_processed_at Feld mit NOW() befüllen (und in die DB speichern)
  • Folgende Bedingungen überprüfen:
    • Das FeatureGate silverscouts.invitation ist enabled. Deckt fachliches Kriterium 10. ab.
    • Die Person hat keine aktiven Rollen im Layer (inkl. Untergruppen, aber nicht Unter-Layers) wo die beendete Rolle war. Deckt fachliche Kriterien 1., 2. und 7. ab.
    • Falls die gelöschte Rolle in einer der folgenden Gruppentypen war, muss die Person ein Geburtsdatum haben und älter als 16 Jahre sein: Group::Biber, Group::Woelfe, Group::Pfadi, Group::Pio, Group::Pta. Deckt fachliche Kriterien 4. und 6. ab.
    • Die gelöschte Rolle ist keine Ehemaligenrolle. Konkret darf die Rolle kein Group::Ehemalige::Mitglied oder Group::Ehemalige::Leitung sein, und die Gruppe der Rolle ist keine Group::Silverscouts::Region, Group::Silverscouts oder Group::Root. Deckt fachliches Kriterium 5. ab.
    • Die Person hat eine Haupt-Mailadresse. Deckt fachliches Kriterium 8. ab.
    • Die Person hat keine aktiven Ehemaligenrollen irgendwo in der Datenbank. Konkret muss für alle aktiven Rollen der Person gelten: Es darf kein Group::Ehemalige::Mitglied oder Group::Ehemalige::Leitung sein, und die Gruppe der Rolle ist keine Group::Silverscouts::Region, Group::Silverscouts oder Group::Root. Deckt fachliches Kriterium 9. ab.
  • Falls sämtliche Bedingungen zutreffen: Ein neues Custom Content Mail (z.B. mit dem Key ALUMNI_INVITATION_WITH_REGIONAL_ALUMNI_GROUPS) versenden
    • Placeholder {person-name}: Name der Person deren Rolle beendet wurde
    • Placeholder {SiScRegion-Links}: Eine HTML-Liste mit Links zur Selbstregistrierungsseite allen Gruppen vom Typ "Group::Silverscouts::Region", welche Selbstregistrierung aktiviert haben
      • Die Links sollten ungefähr so aussehen: <a href="[self_inscription_link]" target="_blank">[group_name]</a>
    • Placeholder {AlumniGroup-Links}: Eine HTML-Liste mit Links zur Selbstregistrierungsseite aller Ehemaligengruppen von der Rolle aus aufwärts im Baum. Die Suche soll folgendermassen ablaufen:
      1. Auf dem Layer der Rolle starten. (Falls Rolle bereits auf einem Layer war, auf diesem Layer bleiben. role.group.layer_group müsste ungefähr gehen)
      2. Wenn das aktuelle Layer die PBS oder der Root-Knoten ist, dann Suche beenden.
      3. Sämtliche Untergruppen (und Unter-Untergruppen) vom Typ Group::Ehemalige dieses Layers suchen, welche Selbstregistrierung aktiviert haben, und sie zur HTML-Liste hinzufügen. Siehe Nested Set Doku für Details wie man diesen Query effizient machen kann.
      4. Mit dem nächsten übergeordneten Layer bei Schritt b. weiterfahren.
    • Die Links sollten ungefähr so aussehen: <a href="[self_inscription_link]" target="_blank">[layer_name]: [ehemalige_gruppe_name]</a>
    • Falls keine selbstregistrierbaren Ehemaligengruppen aufwärts im Baum gefunden wurden, stattdessen ein anderes CustomContent Mail mit dem Key ALUMNI_INVITATION_WITHOUT_REGIONAL_ALUMNI_GROUPS versenden, welches nur die {person-name} und {SiScRegion-Links} Placeholder enthält.
• Täglich laufenden AlumniReminderJob erstellen
  • Funktioniert genau gleich wie der AlumniInvitationsJob (kann je nach dem auch davon erben). Einzige Unterschiede:
  • Statt alumni_invitation_processed_at arbeitet diese Job mit dem Feld alumni_reminder_processed_at
  • Statt 3-6 Monate sucht dieser Job nach allen Rollen die vor 6 Monaten oder älter beendet wurden
  • Das Custom Content Mails sind separat vom anderen Job befüllbar (also ein anderer Key, z.B. ALUMNI_REMINDER_WITH_REGIONAL_ALUMNI_GROUPS / ALUMNI_REMINDER_WITHOUT_REGIONAL_ALUMNI_GROUPS)
• Die zeitlichen Bedingungen für die gelöschten Rollen (3 Monate bzw. 6 Monate) im PBS-Wagon settings.yml einfach konfigurierbar machen

[nchiapol]

Das Ticket scheint auch für uns interessant. (Auch wenn wir wohl keinen SilverCevi-Baum einführen werden und aktuell noch keine Ehemaligengruppen haben.)

Ich kann mir vorstellen, dass wir den Gruppentyp "Ehemalige" einbauen und dann wären wir sehr an dieser Funktionalität interessiert. Aus meiner Sicht könnte das also genre auch in den Youth-Wagon oder gar den Core.

Eine Rückfrage zu @Michael-Schaer's Antwort: Erzeugen "Selbstregistrierungen" keine Dubletten? (Wenn ich bei uns aktuell eine Selbstregistrierung [1] durchführe erhalte ich die Warnung "E-Mail wird bereits verwendet. Melde dich an oder registrier dich mit einer anderen E-Mail-Adresse.")

[1] Ich verstehe darunter den Link "Externe Registrierung" bei der Gruppen-Info. Oder gibt es da bei euch eine weitere Funktion?

[Michael-Schaer]

@nchiapol Das ist tatsächlich etwas schade, wenn wir am Schluss so verschiedene Ehemaligen-Lösungen haben. Wir haben das auch schon mit Puzzle besprochen und die einfachste Lösung ist leider, das im PBS-Wagon zu machen. Die Jubla hat bereits ihre Lösung im eigenen Wagon, unsere ist recht unterschiedlich und das zusammen zu bringen, lohnt sich nicht wirklich. Ob das etwas ändert, wenn ihr euch auch für die hier beschriebene Lösung interessiert, müsste man wohl noch einmal mit Puzzle besprechen.

Eine Rückfrage zu @Michael-Schaer's Antwort: Erzeugen "Selbstregistrierungen" keine Dubletten? (Wenn ich bei uns aktuell eine Selbstregistrierung [1] durchführe erhalte ich die Warnung "E-Mail wird bereits verwendet. Melde dich an oder registrier dich mit einer anderen E-Mail-Adresse.")

Da hast du Recht. Ich dachte eigentlich, das wäre als eingeloggte Person auch möglich. Aber hier müssen wir wohl noch mal nachbessern. Wenn wir das gleich richtig machen wollen, vermutlich so:

• Neue Route (z.B. /de/groups/462/self_inscription)
• self_inscription ist an die Selbstregistrierung gekoppelt und wird auch damit aktiviert/deaktiviert
• self_inscription zeigt auf eine Bestätigungsseite "Möchtest du der Gruppe X beitreten?"
• Wenn nicht eingeloggt, wird die Login-Maske angezeigt und auf die Bestätigungsseite weitergeleitet
• Beim Beitritt wird ein Mail verschickt, analog Selbstregistrierung

[carlobeltrame]

@Michael-Schaer Diese Selbst-Einschreibung fehlt bisher noch komplett, und diese müsste man erst programmieren. Möchtet ihr das gleich im Rahmen dieses Tickets erledigen lassen? Dadurch könnte sich die Offerte allenfalls nochmals ändern (ich bin nicht sicher, ob das bereits in der Offerte so eingerechnet wurde). Als Alternative könnte man auch z.B. die Kontakt-Mailadresse der Ehemaligengruppen ins Mail rendern, wo eine gesetzt ist. Dann können sich die Leute bei den jeweiligen Gruppen selber melden, und dort hinzugefügt werden (wird Zugriffsanfragen auslösen, aber diese kann die ehemalige Person auch selber freigeben).

Noch andere Fragen die sich mir gestellt haben:

• Ist es egal, wenn ich das Enddatum einer Rolle z.B. auf "vor einem Jahr" setze (etwas weil es letztes Jahr vergessen wurde, jemanden auszutragen), und diese Person dann keine Benachrichtigungen bekommt? Das würde die Implementation vereinfachen, weil wir dann einfach einen täglichen Job implementieren können, der alle Rollen heraussucht, deren Enddatum genau 3 bzw. 6 Monate in der Vergangenheit liegt. Andernfalls müssten wir uns für jede einzelne gelöschte Rolle merken, ob die erste und zweite Benachrichtigung bereits versendet wurde, oder pro Rolle einen eigenen Job über 3 bzw. 6 Monate in der DB speichern, bis er dann endlich ausgeführt werden darf.
• Es steht aktuell als Abbruchbedingung "Es hat vorher noch keine Ehemaligenrolle in dieser Ebene existiert". Was wenn die Person nach 3 Monaten das Mail bekommt, und nur den SilverScouts beitritt, aber keiner Ehemaligengruppe der eigenen Ebene? Oder nur einer Ehemaligengruppe der kantonalen Ebene beitritt, aber sonst nirgends? Müsste diese Bedingung nicht eher heissen "Es hat vorher noch keine Ehemaligenrolle in dieser Ebene aufwärts oder in den SilverScouts existiert"? Oder müssten wir separate Mails für SilverScouts-Mitgliedschaft und APV-Mitgliedschaften versenden, die jeweils ihre eigenen Bedingungen haben?

[Michael-Schaer]

Diese Selbst-Einschreibung fehlt bisher noch komplett, und diese müsste man erst programmieren. Möchtet ihr das gleich im Rahmen dieses Tickets erledigen lassen?

Siehe hitobito/hitobito#2180. Vielleicht könnt ihr den PR bei der Umsetzung mit einbeziehen?

Ist es egal, wenn ich das Enddatum einer Rolle z.B. auf "vor einem Jahr" setze?

Dieser Fall muss nicht beachtet werden, da er sehr selten ist

Was wenn die Person nach 3 Monaten das Mail bekommt, und nur den SilverScouts beitritt, aber keiner Ehemaligengruppe der eigenen Ebene?

Guter Punkt. Vorschlag: Wenn die Person in irgendeiner Ehemaligen-Gruppe eine Rolle hat, sollte das Mail nicht verschickt werden.

[carlobeltrame]

@Michael-Schaer hast du noch einen (vorerst nur deutschen) Beispiel-Text für das Mail, inkl. Verwendung der beiden Platzhalter? Es wäre hilfreich um beim Entwickeln genau zu verstehen wofür das Mail gedacht ist, und wir könnten den Text dann auch gleich als Default erfassen.
Ich habe jetzt mal vorgesehen dass nach 3 und 6 Monaten unterschiedliche Mailtexte erfasst werden können, der Aufwand dafür ist nicht wirklich höher als wenn der Mailtext immer gleich sein müsste. Aber achtung: Nach aktuellem Detailkonzept ist es auch möglich dass mal nur das zweite Mail versendet wird, nämlich wenn ich eben das Enddatum einer Rolle auf z.B. vor 10 Monaten setze. Ich habe vorgesehen dass wir dann verhindern, dass gleichzeitig das 3-Monate und das 6-Monate-Mail rausgehen, aber das 6-Monate-Mail geht nach aktuellem Plan immer noch raus.

[Michael-Schaer]

@carlobeltrame Ich habe mal ein Mail inkl. Pseudocode aufgesetzt. Den Text werden wir sicher noch anpassen, symbolisch passt er aber. Ich dachte an zwei Variablen, die im Mail frei eingesetzt werden können. Bei der zweiten Variable ist etwas ungünstig, dass diese selber einen längeren Text enthält, der dann vermutlich nicht konfigurativ ist(?)
Ich habe aber gerade nicht gesehen, wie wir das besser lösen könnten.

Liebe Nala

Ich habe festgestellt, dass du in der Mitgliederdatenbank der PBS keine Rolle mehr hast. Ich möchte dich darauf hinweisen, dass wir Benutzeraccounts, die nicht mehr verwendet werden, mit der Zeit löschen.

Du hast verschiedene Möglichkeiten, um weiterhin mit der Pfadi in Kontakt zu bleiben. Wir würden dich gerne einladen, Silverscout zu werden und dich mit anderen ehemaligen Pfadis auszutauschen. Schreibe dich dafür in einer oder mehreren der folgenden SilverScouts-Gruppen ein. Du kannst dich dafür dem Link unten folgen und dich mit deiner E-Mail-Adresse und deinem Passwort einloggen. Mehr Infos zu den Silverscouts findest du auf der PBS-Webseite.

<SiSc-Regions>
foreach sisc_region {
  - <a href="[self_inscription_link]" target="_blank">Region [group_name]</a>
}
</SiSC-Regions>

<Tree-Groups>
if (has_ehemalige_gruppe_in_tree) { # check for every role, only if self_inscription is active
  Ich habe ausserdem folgende Ehemaligengruppen gefunden, die für dich spannend sein könnten. Du kannst dich 
  ebenfalls via Link direkt für diese einschreiben: 

  foreach ehemalige_gruppe_in_tree
    - <a href="[self_inscription_link]" target="_blank">[group_name]: [ehemalige_gruppe_name]</a>
  }
}
</Tree-Groups>

[carlobeltrame]

Merci vielmals für den Text. Was im Rahmen dieses Issues (und der offerierten Zeitschätzung) sicher nicht möglich sein wird, ist eine "Skriptsprache" mit foreach und if einzuführen. Bisher funktionieren die Platzhalter in den Mailtexten via simples String Replace. Anhand der ursprünglichen Beschreibung "zwei Variablen {SiScRegion-Links} und {AlumniGroup-Links}" habe ich es mir ungefähr so vorgestellt:

Hallo {person-name}

Ich habe festgestellt, dass du in der Mitgliederdatenbank der PBS keine Rolle mehr hast. Ich möchte dich darauf hinweisen, dass wir Benutzeraccounts, die nicht mehr verwendet werden, mit der Zeit löschen.

Du hast verschiedene Möglichkeiten, um weiterhin mit der Pfadi in Kontakt zu bleiben. Wir würden dich gerne einladen, Silverscout zu werden und dich mit anderen ehemaligen Pfadis auszutauschen. Schreibe dich dafür in einer oder mehreren der folgenden SilverScouts-Gruppen ein. Du kannst dich dafür dem Link unten folgen und dich mit deiner E-Mail-Adresse und deinem Passwort einloggen. Mehr Infos zu den Silverscouts findest du auf der PBS-Webseite.

{SiScRegion-Links}

Ich habe ausserdem folgende Ehemaligengruppen gefunden, die für dich spannend sein könnten. Du kannst dich ebenfalls via Link direkt für diese einschreiben:

{AlumniGroup-Links}

An der Stelle der Platzhalter würden dann gemäss meinem aktuellen Plan direkt ausprogrammierte (HTML-)Aufzählungen mit Verlinkungen ins Mail eingesetzt.

Für den Fall dass keine Ehemaligengruppen in der Hierarchie aufwärts gefunden werden: Erst mal, ist das denn ein realistischer Fall? Gibt es Kantone in denen es keinen APV gibt der sich so präsentieren würde? Wird es keine Ehemaligengruppe auf Ebene PBS geben?
Falls es diesen Fall wirklich realistisch gibt, sehe ich zwei Möglichkeiten.

1. Wir könnten im Code einprogrammieren, dass der {AlumniGroup-Links} Platzhalter leer gelassen wird, wenn keine Ehemaligengruppen gefunden werden. Wenn aber Ehemaligengruppen gefunden werden, würden wir via Ruby vor der Aufzählung den Satz "Ich habe ausserdem folgende Ehemaligengruppen gefunden, ..." einfügen, und der Inhalt des Satzes wäre via einen "normalen" übersetzbaren Text durch euch änderbar (aber nicht direkt im "Texte" Menü ohne einen Release).
2. Alternativ könnten wir zwei unterschiedliche Custom Content Mails einrichten, eines für den Fall dass es Ehemaligengruppen gibt, und eines für den Fall dass es keine gibt. Dann habt ihr volle Kontrolle über die Fliesstexte, müsst aber mehr Texte übersetzen und up to date halten.

[carlobeltrame]

Achtung: Der Text den du mir geschickt hast enthält übrigens noch einen Widerspruch mit deiner Spezifikation. Du schreibst "Ich habe festgestellt, dass du in der Mitgliederdatenbank der PBS keine Rolle mehr hast." In der Spezifikation ist aber nicht die Rede von "keine Rolle in der Mitgliederdatenbank", sondern nur von "Die letzte aktive Rolle der Person in dieser Gruppe und Ebene wurde gelöscht" (emphasis mine). Es werden also gemäss deiner aktuellen Spezifikation auch Personen das Mail bekommen, die durchaus noch aktive Rollen haben, aber einfach z.B. in einer von mehreren Abteilungen / Ebenen aufgehört haben.

[Michael-Schaer]

Erst mal, ist das denn ein realistischer Fall? Gibt es Kantone in denen es keinen APV gibt der sich so präsentieren würde?

Die Ehemaligengruppen kommen ja nach dem Release erst nach und nach dazu. Dann müssten sie auch noch die Selbst-Einschreibung aktiviert haben. Irgendwann entscheiden wir uns dann, das Mail zu aktivieren. Da werden vermutlich weitaus nicht alle Ebenen eine Ehemaligen-Gruppe haben.

Wird es keine Ehemaligengruppe auf Ebene PBS geben?

Nein, die SiSc-Regionen sind ja im anderen Knoten.

Falls es diesen Fall wirklich realistisch gibt, sehe ich zwei Möglichkeiten.

Beide funktionieren für mich. Wichtig ist, dass wir das Mail beim Start, sowie temporär nur mit einer der beiden Variablen verwenden können.

Widerspruch
Stimmt, den Teil mit "keine Rolle" und auch die Info zur Löschung kannst du ignorieren. Die haben wir auch im hitobito/hitobito#2106 (comment) nicht mehr drin (das war am Anfang noch anders).

[carlobeltrame]

Irgendwann entscheiden wir uns dann, das Mail zu aktivieren.

Wie meinst du das mit aktivieren? Muss der Mailversand-Automatismus als ganzes (de-)aktivierbar sein? Reicht es wenn wir das als FeatureGate in den settings.yml konfigurierbar machen und somit ein Deployment nötig ist um es umzuschalten?

[Michael-Schaer]

Siehe auch Punkt 10. ganz oben. Das muss nicht zwingend "on the fly" sein.

Für mich ergibt sich dadurch folgender Einführungsplan / Ablauf:

• ReleaseNotes verschicken
• Release
• Konfiguration / Erfassung
  • PBS: Konfiguration des E-Mails (zwei Variablen: SiSc-Gruppen und Ehemaligen-Gruppen)
  • PBS: SiSc-Regionen erfasssen, Selbstregistrierung aktivieren
  • PBS: SiSc-Benutzer migrieren
  • Abteilungen+: Ehemaligengruppen erfassen, Selbstregistrierung aktivieren

3 Monate nach Release:

• Puzzle: Mail / Automatismus aktivieren
• PBS: Verschickt das Mail manuell an Benutzer, die ein Jahr vor dem Release bis zum Release ihre Rolle verloren haben (diese sollen auch die Möglichkeit haben, sich einzuschreiben)

Habe ich alles richtig verstanden? Bzw. passt das mit der technischen Spezifikation zusammen?

[carlobeltrame]

Ja, den Punkt 10 hatte ich gestern noch provisorisch ergänzt. Gut wenn du dem zustimmst.

Das Vorgehen passt. Wenn ihr wollt können wir euch auch das manuelle Mail ersparen, indem wir beim Release nur gelöschte Rollen mit "Löschdatum < vor 1 Jahr" als "bereits erledigt" markieren.