Bemerkungen bei Anlässen, Kursen und Lager löschen

[Michael-Schaer]

Bei Kursen werden manchmal Essgewohnheiten (vegetarisch, vegan) im Bemerkungsfeld erfasst. Da es sich dabei um heiklere Benutzerdaten handeln könnte, sollen diese nur solange gespeichert werden, wie sie auch vom Küchenteam benötigt werden.

Als Ergänzung von #1060 soll deshalb die Bemerkung von Kursen, Lagern und Anlässen regelmässig gelöscht werden. Dies soll ebenfalls 3 Monate nach Durchführung des Kurses, Lagers oder Anlasses passieren.

Der Hilfetext für das Feld existiert bereits. Dort können wir informieren, dass die Daten nicht persistent sind:

Ergänzungen

• Es darf nur das letzte Datum für die Löschung berücksichtigt werden (Events können mehrere Daten haben).
• Es ist nicht nötig, die Daten im Backup zu löschen. Das Backup ist etwas träger im Vergessen. Das ist in diesem Fall ok so.
• Die Funktion soll wenn möglich im Core umgesetzt werden
  • Dauer bis zur Löschung konfigurierbar
  • Per Config aktivierbar

Tech-Spec

• Umsetzung im Core, aber standardmässig "deaktiviert" via eine extrem lange Frist
• Dauer via settings.yml setzbar
• Vorläufig scheint es den Aufwand nicht wert, eine extra Datumsspalte auf dem Event einzufügen, sodass der Event nur einmal verarbeitet wird. Daher iterieren wir einfach täglich über sämtliche alten Participations.
• Sollte vor dem produktiv schalten mal noch mit einem PBS-DB-Dump durchgetestet werden, um festzustellen ob das Aktualisieren derart vieler Participations in sinnvoller Zeit machbar ist

ToDo

• In settings.yml eine neue Einstellung event.participations.delete_additional_information_after_months, default sehr hoch wählen, z.B. 1200 Monate
• Im PBS Wagon diese Einstellung auf 3 Monate setzen
• Wieder im Core: Neuer täglich laufender Delayed::Job (Beispiel siehe hier)
  • Job sucht nach Event::Participations, bei denen das letzte event_date des Events seit mehr als x Monaten beendet ist (wobei x die neue Einstellung aus settings.yml ist)
  • Bei all diesen Participations die Spalte additional_information auf nil oder leeren String setzen
  • Falls das Setzen in Rubyland passiert, unbedingt find_in_batches o.ä. verwenden. Falls ein direktes DB-Statement möglich ist, umso besser
• Mit einem PBS-DB-Dump testen, um herauszufinden wie lange der Job braucht und ob man trotzdem besser eine "erledigt_am" Spalte auf die Events-Tabelle machen würde
• Specs schreiben
• Mit angemessener Rolle "durchklicken"
• CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

[nchiapol]

Einer Umsetzung im Core steht aus meiner Sicht nichts im Weg. Ein Config-Option um das zu aktivieren ist aus meiner Sicht nicht nötig. Es reicht, wenn die Dauer bis zur Löschung auf z.B. 99 Jahre gesetzt werden kann.

Wir fragen die Essgewohnheiten (vegetarisch, vegan) üblicherweise als separate Anmeldungsfrage ab. Sollten diese ebenfalls einbezogen werden? Aus meiner Sicht ist das nicht nötig, da ich Essgewohnheiten nicht als heikel betrachte. Schützenswert sind Gesundheitsinformationen und Allergien und die sind mindestens bei uns fix in den Bemerkungen.

[richardjubla]

Ich finde das eine interessente, pragmatische Lösung die ich mir ebenfalls so wie beschreiben im Core/Youth vorstellen könnte.
(Interesse von Seite jubla ist definitiv da)

Gedanken:

• Config-Option aus meiner Sicht auch nicht nötig (Dauer könnte fix sein)
• Die Mischung und Ergänzung der "Bemerkungen" um spezifische Felder liess mich nachdenken, ob und welche Felder länger oder ebenfalls gelöscht werden könnten. Teilweise werden die Felder "länger" benötigt, dann wiederum wäre eine Zeitnahme Löschung möglich.
• Jedem Feld die Option für "Feld X Tage nach Event löschen" zu ergänzen ist technischer Overkill
• Wahrscheinlich werden sich die Events mit dem neuen Feature angleichen: Sowohl Event-Organisatoren und Personen die sich Anmelden werden das Feld eher oder gemäss ihrem Befinden benutzen.

[patrickuhlmann]

Was ich nützlich fände wäre wenn bei den Feldern die effektiv kurz nach dem Kurs gelöscht werden ein entsprechender Hinweis angebracht ist oder die Felder speziell markiert sind. Als Teilnehmer/Eltern würde ich es beruhigend finden das zu sehen wenn ich dort Gesundheitsinformationen etc. angeben soll und als Leiter wäre es nützlich damit ich nicht aus Versehen etwas eingebe was dann kurze Zeit später weg ist obwohl das gar nicht der Fall sein soll.

[carlobeltrame]

@patrickuhlmann im Issue ist bereits folgendes erwähnt:

Der Hilfetext für das Feld existiert bereits. Dort können wir informieren, dass die Daten nicht persistent sind:

Ausserdem könntet ihr via Übersetzungstexte auch das Label "Bemerkungen (Allgemeines, Gesundheitsinformationen, Allergien, usw.)" anpassen. Reichen diese zwei Optionen aus deiner Sicht (und aus Sicht von @Michael-Schaer) als Hinweis? Oder müssen wir da noch etwas dazubauen?

[carlobeltrame]

@Michael-Schaer noch als Hinweis, weil es beim Refinement aufgefallen ist: Bei der Einführung dieses Features (und auch falls die 3-Monate-Frist mal geändert wird) werden im ersten Moment mal massenhaft alte Bemerkungsfelder gelöscht werden. Ich nehme an das ist okay und sogar gewünscht so.

[richardjubla]

@Michael-Schaer noch als Hinweis, weil es beim Refinement aufgefallen ist: Bei der Einführung dieses Features (und auch falls die 3-Monate-Frist mal geändert wird) werden im ersten Moment mal massenhaft alte Bemerkungsfelder gelöscht werden. Ich nehme an das ist okay und sogar gewünscht so.

Dieser Aspekt ist auch in #2238 vorhanden: Hier sollen auch vergangene Events einbezogen werden: Die Lösung soll und darf alle Events betreffen. Dies bedeutet, dass auch Event-Anmeldungen (inkl. PDF?) aus vergangenen Jahren mit einem Release bereinigt würden.

[patrickuhlmann]

@patrickuhlmann im Issue ist bereits folgendes erwähnt:

Der Hilfetext für das Feld existiert bereits. Dort können wir informieren, dass die Daten nicht persistent sind:

Ausserdem könntet ihr via Übersetzungstexte auch das Label "Bemerkungen (Allgemeines, Gesundheitsinformationen, Allergien, usw.)" anpassen. Reichen diese zwei Optionen aus deiner Sicht (und aus Sicht von @Michael-Schaer) als Hinweis? Oder müssen wir da noch etwas dazubauen?

Nein dann sollte das reichen.