AHV-Nummer vom Profil in den Event verschieben

[ThomasEllenberger]

Umsetzungsticket aus der Diskusion von https://github.com/hitobito/hitobito/issues/2162

Da den Organisationen welche heute die AHV-Nummer in Hitobito verwalten die gesetzliche Grundlage fehlt, um die AHV Nummer persistiert auf Personen zu speichern, soll diese neu nur noch dort gespeichert werden, wo sie verwendet wird. Die AHV-Nummer wird nur bei Events von J+S benötigt und nur zum Zeitpunkt des Exports für die NDBJS. Aus diesem Grund soll die AHV Nummer nur noch auf dem Event gespeichert und x Tage nach der Durchführung von dort wieder gelöscht werden. Ob die AHV Nummer bei einem Event benötigt wird oder nicht soll man einstellen können. Wie Lange die AHV Nummer gespeichert wird ist pro Wagon definierbar und entspricht dem gleichen Zeitraum wie auch die restlichen Anmeldeangaben gespeichert werden.

Ausgangslage:

• Für die Anmeldung von Personen in der NDS wird weiterhin die AHV-Nummer benötigt.
• Zukünftig wird diese jedoch nur noch für die erste Meldung einer Person in einer Organisation benötigt. Bei weiteren Events in der gleichen Organisation braucht es die AHV-Nummer nicht mehr zwingend.
• Für das konstante speichern der AHV-Nummer in Hitobit fehlt die gesetzliche Grundlage. Auch eine Einwilligung der Eltern befähigt uns nicht, diese länger als zwingend notwendig zu speichern.

MVP-Hitobito:

• Auf Events wird eine neue Frage für die AHV Nummer bei den Anmeldeangaben hinzugefügt, Analog den "Bemerkungen".
  • Die Frage gibt es automatisch auf allen Events (Anlässe, Kurse, Lager).
  • Für die Frage hat es drei Bulletpoints zur Auswahl: "Obligatorisch", "Optional" und "Nicht angezeigt" analog den Kontaktangaben.
  • Per Default ist keine Option ausgewählt.
  • Damit der Event gespeichert werden kann muss zwingend eine Option ausgewählt werden.
  • Es gibt einen Hilfetext welcher pro Umgebung ausgefüllt werden kann.
• Sämtliche Anmeldeangaben und Administrationsangaben werden nach einer gewissen Zeit automatisch gelöscht.
  • Zeitraum ist pro Wagon definierbar.
  • Betrifft alle Fragen welche unter "Anmeldeangaben" erfasst werden.
  • Analog #2129
• Alle NDS-Exporte werden angepasst, damit sie neu das Kursfeld AHV-Nummer ausgeben und nicht mehr das Feld AHV-Nummer in den Personendaten.

Abgrenzung:

In einem zweiten Schritt sollen die bestehenden AHV- Daten gelöscht und auf alle aktiven Kurse übertragen werden. Des wird im Issue #59 umgesetzt.

Tech-Spec

• Eingabefelder, Validierung und Referenzen auf AHV-Nummer löschen
• Standardfrage hinzufügen (Zusammenspiel mit aktuell existenten Standardfragen sicherstellen: jubla hat solche)
• Standardfragen auch verstecken können
  • entweder weiteres Feld "hidden" und validierung, dass es nicht hidden und required sein kann
  • oder umstellung auf enum, um required/optional/hidden abzudecken
• HelpText per Migration anlegen und integrieren, um Hilfetext einstellbar zu machen
• Event::ParticipationCleanupJob anpassen, um alle Anmeldeangaben nach der Frist zu löschen
• NDS-Exporte anpassen

ToDo

• [x] Standardfrage nach AHV-Nummer zu Events hinzufügen
• [x] Standardfragen versteckbar machen
• [x] Event::ParticipationCleanupJob anpassen, um alle Anmeldeangaben nach der Frist zu löschen (=> ist schon erledigt mit https://github.com/hitobito/hitobito_sac_cas/issues/367)
• [x] NDS-Exporte anpassen
• [ ] Hilfetext per Migration anlegen
• [ ] Hilfetext einstellbar machen
• [x] Specs schreiben
• [ ] Kunde wegen Übersetzungen informieren
• [x] Mit angemessener Rolle "durchklicken"
• [x] CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

Noch offen

• [ ] Eingabefelder für AHV-Nummer verstecken (vorerst noch offen, wird mit #59 gemacht!)
• [ ] Validierung für AHV-Nummer löschen (vorerst noch offen, wird mit #59 gemacht!)
• [ ] weitere Referenzen auf AHV-Nummer prüfen und möglichst entfernen (vorerst noch offen, wird mit #59 gemacht!)

[richardjubla]

Hinweis zur Umsetzung

~~Uns ist der Zeitpunkt der Umsetzung (produktiv schalten) ein sehr wichtiges Anliegen: Entweder auf den Quartalsrelease 2/24 (Di, 2. Juli) ODER den Quartalsrelease 3/24 (Di, 01. Oktober) abhängig von einem Entscheid im Juni. Zu diesem Zeitpunkt hat die Nationale Datenbank Sport (NDS) angekündigt, eine Lösung für die AHV-Nr. bereit zu haben: In der NDS sollen dann bereits bekannte AHV-Nummer mit importierten Daten kombiniert werden können. Unsere Anpassung könnte und soll gleich daran anschliessen. Sollte es zu Verzögerungen kommen, wären wir für einen Release im Oktober vorbereitet und könnten uns kommunikativ/unterstützend für unsere Scharen vorbereiten. Zusätzlich oder alternativ könnte die Dauer der temporären Speicherung der Daten im Event angepasst werden. (1. Release 12 Monate / 2. Release 3 Monate) Hintergrund: Die AHV-Nr. ist für mache eine «mühsame» Sache, weil sie insbesondere bei Kindern nicht so einfach zu bekommen ist oder vergessen geht. Der (emotionale) Verlust der AHV Nr. in den Profilen der Mitglieder soll damit kompensiert werden, dass diese eben zukünftig bereits in der NDS automatisch zugeordnet werden. Die youth-Verbände werden die Lager-Administration (Lagerleitung/Coach) in Abhängigkeit mit der NDS-Fähigkeiten auf die Umstellung sensibilisieren und schulen. Du kannst dich darauf verlassen, dass wir (youth-Verbände) uns dazu austauschen.~~

Da der Mergefreeze für den July release bereits Mitte Juni anfängt, ist ein Entscheid Anfang Juni zu knapp. Arbeiten sollen im 3. Quartal stattfinden und die Änderungen mit dem Oktober Release produktiv umgesetzt werden.

[tschuepbach]

Update seitens NDS: Die Anpassung des Imports in der NDS wird für die Jugendausbildung Ende Juli umgesetzt. Die Anpassungen für die Kaderbildung erfolgt im Oktober. Somit ist eine Umsetzung in Q3 passend und sinnvoll.

[richardjubla]

Als FG Datenbank möchten wir Scharen und Event-Veranstalter entlasten, dass sie nicht notwendige oder nicht legitimierbare Daten unbeschränkt aufbewahren. Dazu sollen die Antworten zu Events nach x Monaten automatisch gelöscht werden, damit dies der Vorstand oder die Event-Administration nicht manuell machen muss.

Wir beziehen uns auf https://github.com/hitobito/hitobito_sac_cas/issues/367 und https://github.com/hitobito/hitobito_sac_cas/issues/367

Vorgabe:

• Mit dem Release wird der Wert auf 5 Jahre (60 Monate) gesetzt und im Verband über die jubla.db (Release/Handbuch) kommuniziert. (Maximal rechtlich vertretbarer Nachweis für Event-Angaben). Mit einem folgenden Release soll der Wert dann auf 13 Monate gesenkt werden. (Damit haben die Scharen Zeit, allfällige Archiv-Wünsche oder spezielle Anforderungen abzudecken).

Vorgeschlagene Werte:

Settings.event.participations.delete_additional_information_after_months = 60
Setting.sevent.participations.delete_answers_after_months = 60

[diegosteiner]

Für die technische Umsetzung habe ich mit @ThomasEllenberger und @kronn folgende zusätzliche Punkte besprochen:

• Damit man bei einer Standardfrage neu entscheiden kann, ob Sie für diesen Event obligatorisch, optional oder versteckt sein soll, müssen diese Standardfragen beim Erstellen des Events kopiert (anstatt nur verknüpft werden). Das betrifft dann alle Standardfragen und muss auch rückwirkend für alle bestehenden Events per Migration gemacht werden.
• Standardfragen können dann, anders als bei normalen Anmelde-/Administrationsangaben nicht entfernt werden (was aktuell ja aber auch nicht der Fall ist). Man kann aber ja entscheiden, dass die Anmeldeangabe einfach nicht angezeigt wird. Dies wird aber nur im UI gemacht, mutwillige Manipulation des Browsers wäre trotzdem möglich.
• In der jetzigen Spezifikation fehlt eine Validierung für die AHV-Nummer. Das wäre aber meiner Ansicht nach sehr wichtig. Umsetzen können wir das, indem wir Fragen neu einen Typ zuweisen. Damit wären auch spätere Erweiterungen mit zusätzlichen Typen möglich. Da es aber noch keinen Use-case gibt, wird der Typ nur bei der neuen AHV-Nummer Frage verwendet. Aus dem UI gibt es (noch) keine Möglichkeit, einen Typ auszuwählen.
• Zu beachten bei der Umsetzung ist, dass die bestehenden Standardfragen (z.B. bei der Jubla) nicht die Standardfragen aus dem youth_wagon überschreiben, sondern nur ergänzen müssen

@ThomasEllenberger habe ich etwas vergessen?

[diegosteiner]

Ich habe den Prototypen soweit mal umgesetzt:

[diegosteiner]

ref https://github.com/hitobito/hitobito_sac_cas/issues/367

[diegosteiner]

@ThomasEllenberger wir hatten gestern noch darüber diskutiert, ob man die Standardfragen nicht «unveränderbar» machen kann. Ich habe das testweise mal umgesetzt und bin jetzt recht überzeugt, dass das die sinnvollste Variante ist. Es würde dann etwa so aussehen:

[richardjubla]

So wie ich das verstehe, werden die "Standardfragen" im jubla-Wagon weiterhin lediglich bei Kursen sichtbar und "verwendbar" sein. (organisatorisch für den User weitgehend irrelevant, wie und wann die Fragen kopiert oder verknüpft werden.) Ich begrüsse explizit, dass standardisierte und unveränderbare Fragen gibt.

Die die Administrationsangaben nur mit der manuellen Zuteilung ausgefüllt werden können, können sie nicht für die AHV Nr. verwendet werden. Es wäre wichtig, dass die AHV-Nr. nicht für alle Lagerteilnehmer*innen sichtbar wird, selbst wenn sie sich gegenseitig sehen können (Option: event_participations_visible)

[richardjubla]

Neu sind "Antwort obligatorisch ist kein gültiger Wert", sofern Standardfragen oder in den Administrationsangaben eine Frage

Workaround: Frage in den Administrationsangaben löschen, Anlass speichern und Frage neu anlegen.

[diegosteiner]

Noch eine Ergänzung, die ich sinnvoll fände

Neue Standardfragen (wie z.B. die AHV Nummer) sollten auch bestehenden Events hinzugefügt werden. Mein Vorschlag wäre, dass die Standardfragen sowohl beim Erstellen als auch beim Bearbeiten übernommen werden.

Alternativ oder zusätzlich könnte man auch noch eine Migration machen, welche die AHV-Nummer allen bestehenden Anlässen als (optionale) Frage hinzufügt? Wie seht ihr das @ThomasEllenberger @richardjubla ?

[ThomasEllenberger]

Hey Diego. Die AHV Nummer Frage müsste sicher auch in bestehende Events übernommen werden. Evtl noch nicht in diesem Issue. Es gib ein Folgeissue: https://github.com/hitobito/hitobito_youth/issues/59 durch welches AHV-Nummern von Personen auf bestehende Events übertragen werden sollen. Spätestens dafür müssten in bestehenden Events dann die Frage nach AHV-Nummern auch vorhanden sein.

[diegosteiner]

Es wäre wichtig, dass die AHV-Nr. nicht für alle Lagerteilnehmer*innen sichtbar wird, selbst wenn sie sich gegenseitig sehen können (Option: event_participations_visible)

Ich habe das geprüft; den TN wird gegenseitig «fehlende Berechtigung» angezeigt:

@ThomasEllenberger

[ThomasEllenberger]

@nchiapol hat mich heute noch darauf aufmerksam gemacht, dass im Cevi wagon hier noch etwas nicht korrekt ist:

• Im Cevi Wagon gibt es eine Standartfrage "Ich habe Interesse an einer Mitarbeit im Leiterteam in einer der folgenden Rollen", welche nur in Kursen erstellt werden soll. Aktuell wird diese in allen Anlässen erstellt.
• Die Frage hat mehrere Antwortmöglichkeiten. Diese müssen pro Kurs angepasst werden können und sollen entsprechend im UI erscheinen.
• Aktuell wird die Frage nach der AHV-Nummer doppelt angezeigt.

[richardjubla]

@ThomasEllenberger

[tschuepbach]

@ThomasEllenberger

Die Formulierung der Fehlermeldung ("Application questions disclosure muss ausgefüllt werden") müsste wohl noch sinnvoll "übersetzt" werden..

Und sollte es nicht heissen "Anmeldeangaben sind nicht gültig"? 🤔

[richardjubla]

@ThomasEllenberger

Für die Koordination im Youth-Wagon benötigen zu wissen, wie der Stand dieser Story ist. (Aktuell "unreleased" auf der Stage-Umgebung?). Passiert hier noch was im Marge-Freeze bis 1. Oktober?

[richardjubla]

Als FG Datenbank möchten wir Scharen und Event-Veranstalter entlasten, dass sie nicht notwendige oder nicht legitimierbare Daten unbeschränkt aufbewahren. Dazu sollen die Antworten zu Events nach x Monaten automatisch gelöscht werden, damit dies der Vorstand oder die Event-Administration nicht manuell machen muss.

Wir beziehen uns auf hitobito/hitobito_sac_cas#367 und hitobito/hitobito_sac_cas#367

Vorgabe:

• Mit dem Release wird der Wert auf 5 Jahre (60 Monate) gesetzt und im Verband über die jubla.db (Release/Handbuch) kommuniziert. (Maximal rechtlich vertretbarer Nachweis für Event-Angaben). Mit einem folgenden Release soll der Wert dann auf 13 Monate gesenkt werden. (Damit haben die Scharen Zeit, allfällige Archiv-Wünsche oder spezielle Anforderungen abzudecken).

Vorgeschlagene Werte:

Settings.event.participations.delete_additional_information_after_months = 60
Setting.sevent.participations.delete_answers_after_months = 60

Wie ist hier der Stand? @ThomasEllenberger und @diegosteiner

[richardjubla]

@ThomasEllenberger @diegosteiner

Aktuell macht uns diese Story die Kurse "kaputt":

Die Vorlagen-Fragen werden beim bearbeiten von einem Kurs dupliziert und sind dann doppelt drin. Bei einem neuen Kurs sind sie zwar nicht doppelt drin, können aber nicht bearbeitet werden. Es ist auch nicht ersichtlich, was die Antwort Optionen sind.

[nchiapol]

Ich habe das bei uns eben Getestet und beobachte folgendes Verhalten:

• Die Vorlage-Fragen werden wie von Richi beschrieben beim Bearbeiten eines Kurses hinzugefügt - allerdings nur einmal. Wie in Richis Screenshot ist es aber natürlich möglich, dass eine Standardfrage hinzugefügt wird, die bereits bestand (allenfalls auch aufgrund einer alten Standardfrage). Die alte Frage kann dann aber problemlos gelöscht werden.
• Beim duplizieren eines Kurses oder beim Neu Anlegen funktioniert alles korrekt.

Aus meiner Sicht ist dieses Verhalten soweit ok.

• Es ist vertretbar, dass durch die Migration auf das neue System ein paar manuelle Anpassungen nötig werden. (Wichtig ist, dass wir unsere Nutzer darüber informieren.)
• Dass Standardfragen nicht bearbeitet werden können ist aus meiner Sicht auch vertretbar. Sie können ausgeblendet und stattdessen manuell erfasst werden.

Ein echter Bug ist aber, dass die Antwort-Optionen nicht angezeigt werden.

[richardjubla]

Ich fasse für uns aktuell zusammen:

• Bug: Die Antwort-Optionen von Standardfragen sind nicht sichtbar und müssen sichtbar sein.
• Doppelte Fragen im Produktiven System: Die Kursverwaltungen verwalten aktuell eine Vielzahl an Kursen (ca. 130 Kurse mit über 400 Anmeldungen) und beantworteten Anmelde-Fragen. Die Kurse werden regelmässig "bearbeitet" und aktualisiert. Für uns ist unklar, was dann genau passiert. Voraussichtlich werden wir Doppelte Fragen (alte Standardfragen und neue Standardfragen) haben und viele Antworten verlieren (löschen) oder mit verwirrenden Antwort-Optionen dastehen. Aus Sicht der Kursadministration selbst und für die Kunden ein nicht zumutbarer Zustand.

@nchiapol @ThomasEllenberger

[diegosteiner]

Danke euch beiden für die Rückmeldung. @richardjubla @nchiapol @ThomasEllenberger

• Antwort-Optionen bei Standardfragen anzeigen: einverstanden, für Fragen mit Auswahl müsste das angezeigt werden, das werde ich umgehend beheben.
• Doppelte Fragen: Ich kann die Unsicherheit hier nachvollziehen und schaue mir das nochmals genau an. Ich denke einige der Duplikate sind dem Umstand geschuldet, dass es auf der Integration mehrere Iterationen des Features gegeben hat. Das soll und darf es auf der Produktivumgebung natürlich nicht geben. Ziel ist es, dass:
  1. Für die Benutzer alle Fragen und Antworten auf den Kursen 1:1 bestehen bleiben
  2. Die globalen Fragen aber im Hintergrund auf die Kurse kopiert und verknüpft werden
  3. Die neue globale Frage AHV-Nummer beim Erstellen oder Editieren eines Anlasses hinzugefügt wird.

Stimmt das für euch so oder habe ich etwas grundsätzlich falsch verstanden?

[diegosteiner]

Mein Vorschlag für die Darstellung der Antwort-Optionen bei globalen Fragen:

Würde das das 1. Problem für euch lösen?

[nchiapol]

@diegosteiner Die Doppelten Fragen sind "nicht deine Schuld". Das Problem ist, dass bei laufenden Kursen die gleiche Frage bereits vorhanden ist (weil sie schon im alten Setup [1] als Standard-Frage automatisch angelegt wurde oder weil sie jemand manuell angelegt hat). Ich denke nicht, dass sich das technisch lösen lässt.

[1] Das alte Setup hat einfach bei jedem neuen Kurs Fragen vor-angelegt, die aber sonst identisch waren mit manuellen.

@richardjubla Ich sehe dein Problem bei Kursen, in denen die Anmeldung bereits läuft. Aus meiner Sicht kann das Chaos dort vermieden werden, wenn die neue Standardfrage jeweils auf "nicht anzeigen" gesetzt wird. Dann verhält sich der bestehende Kurs wie bisher. Ob dies manueller gemacht werden kann oder ihr einen Automatismus braucht, hängt wohl von der Anzahl Fragen ab. Wir haben aktuell nur 2 und zusätzliche 2 Klicks vor dem Speichern halte ich für verkraftbar. Zusammenfassend:

• bei bestehenden Kursen beim Bearbeiten jeweils die neun Standard-Fragen auf "nicht anzeigen" setzen.
• beim duplizieren bestehender Kurse jeweils die alten Fragen löschen.
• beim erstellen ganz neuer Kurse: kein Problem.

(Abgesehen von der AHV-Nummer könnten in meinen Augen alle Standardfragen "nicht anzeigen" als default haben, dann wäre der manuelle Aufwand noch kleiner. Wichtig ist mir, dass für alle neuen Anlässe bei der AHV-Frage ein User-Entscheid erzwungen wird. vgl. https://github.com/hitobito/hitobito/issues/2876)

[nchiapol]

@diegosteiner der Mockup für 1. Problem passt so für mich.

[richardjubla]

Doppelte Fragen: Ich kann die Unsicherheit hier nachvollziehen und schaue mir das nochmals genau an. Ich denke einige der Duplikate sind dem Umstand geschuldet, dass es auf der Integration mehrere Iterationen des Features gegeben hat. Das soll und darf es auf der Produktivumgebung natürlich nicht geben. Ziel ist es, dass:

1. Für die Benutzer alle Fragen und Antworten auf den Kursen 1:1 bestehen bleiben
2. Die globalen Fragen aber im Hintergrund auf die Kurse kopiert und verknüpft werden
3. Die neue globale Frage AHV-Nummer beim Erstellen oder Editieren eines Anlasses hinzugefügt wird.

Natürlich wollen wir, dass die bestehenden Antworten auf die Fragen bestehen bleiben. Die Informationen sind für die Durchführung des Kurses wichtig. Bei etlichen Kursen sind also die Standradfragen bereits drin. Wird der Kurs (in Zukunft) bearbeitet entsteht die Situation, dass die "neuen" Standardfragen zusätzlich erstellt werden (diese sind aus gründen nicht bearbeitbar und nicht löschbar). Die Kursadmin hat dann nur noch die Option mit den doppelten Fragen zu leben und die Kunden zu verwirren, oder muss zum Beispiel über manuellen Export/Import alle Teilnehmenden und deren Informationen von den bestehenden Fragen in die neuen Standardfragen mutieren.

[nchiapol]

dass die "neuen" Standardfragen zusätzlich erstellt werden (diese sind aus gründen nicht bearbeitbar und nicht löschbar).

Du kannst sie nicht löschen aber du kannst sie "nicht anzeigen" :arrow_right: Ich verstehe dein Problem nicht.

[diegosteiner]

Natürlich wollen wir, dass die bestehenden Antworten auf die Fragen bestehen bleiben. Die Informationen sind für die Durchführung des Kurses wichtig. Bei etlichen Kursen sind also die Standradfragen bereits drin. Wird der Kurs (in Zukunft) bearbeitet entsteht die Situation, dass die "neuen" Standardfragen zusätzlich erstellt werden (diese sind aus gründen nicht bearbeitbar und nicht löschbar). Die Kursadmin hat dann nur noch die Option mit den doppelten Fragen zu leben und die Kunden zu verwirren, oder muss zum Beispiel über manuellen Export/Import alle Teilnehmenden und deren Informationen von den bestehenden Fragen in die neuen Standardfragen mutieren.

Auf der Integrationsumgebung gab es die Situation, dass die globalen Fragen mehrfach geseeded wurden. Das Problem ist inzwischen behoben, es kann aber sein, dass da noch Folgen davon herumliegen (=> deshalb tauchen die Fragen bei diesem Kurs wohl mehrfach auf). Es ist nicht vorgesehen, dass die globalen Fragen mehrfach auf den Kursen erscheinen, auch beim bearbeiten nicht. Bereits erstellte Kurse behalten die globalen Fragen bei, wie sie waren. Mit der Ausnahme von eben der AHV-Nummer, die es bisher noch auf keinem Kurs gegeben haben kann.

Ich versuche versuche dem Problem auf der Integrationsumgebung auf den Grund zu gehen und stelle sicher, dass es so funktioniert wie es vorgesehen ist.

[richardjubla]

@diegosteiner @ThomasEllenberger Aktuelle Erkenntnis (26.9. 20:29Uhr):

• Die Standard-Fragen werden neu in allen Events eingefügt bis jetzt war dies NUR bei den Kursen der Fall. Unsere Standard-Fragen sind damit eher störend und es ist unklar ob dies ein Feature oder ein Bug ist
• Die Standard-Fragen werden aktuell in alle Events eingefügt und führen dazu, dass bei vielen Anmeldungen in der Vergangenheit (x Jahre zurück) die "Pflichtgangaben fehlen"
• Das Anmeldedatum von eigentlich allen Anmeldungen auf der gesamten Datenbank wird auf das gestrige Datum gesetzt. Es ist als hätten sich alle in allen Events erst gestern angemeldet:

[diegosteiner]

@richardjubla ich bin hier auch gerade noch dran.

• Standard-Fragen in allen Events statt nur in Kursen: habe ich in der Zwischenzeit angepasst, nur die AHV-Nummer soll auf alle Events angewendet werden. In der Integrationsumgebung müssen die Fragen aber durch uns wieder entfernt werden, auf der Produktionsumgebung sollte das nicht der Fall sein (=> ich überprüfe das)
• Standard-Fragen in allen Events führt zu Pflichtangaben ungültig: sollte mit dem oben und der Massnahme, dass bei bestehenden Events neue Fragen als versteckt hinzugefügt werden (gem. Absprache mit @ThomasEllenberger ) gelöst sein (=> ich überprüfe das)
• Das Anmeldedatum ist gestern: das ist mir neu und schleierhaft, ich gehe dem noch nach, das schaffe ich aber heute nicht mehr

Ein zusätzlicher Punkt:

• Aktuell dauert die Migration der Daten ziemlich lange, ich prüfe noch Optionen um den Vorgang zu beschleunigen oder nebenläufig machen zu können, damit das Downtime-Fenster nicht überbeansprucht wird.

[diegosteiner]

@richardjubla so, jetzt haben wir's, glaube ich.

Ich habe mich nochmals intensiv mit den bestehenden Daten auseinander gesetzt und bin zu folgendem Schluss gekommen: die Migration der Standard-Fragen auf bestehenden Events ist Schwachsinn und würde in der Tat zu doppelt vorkommenden Fragen führen. Aktuell ist es bereits so, dass die Standard-Fragen als «Kopie» auf dem Anlass abgelegt wurden. Dementsprechend ist die Strategie viel sinnvoller, die Fragen genau so zu belassen.

Auf der anderen Seite bedeutet das aber auch, dass wir nicht wissen, bei welchen Fragen es sich um Standardfragen handelt. Das könnte zwar über den Text abgeleitet werden, wird aber beliebig kompliziert (=> Fragetext hat sich über die Zeit verändert).

In Kombination mit dem Vorschlag, «neue Standard-Fragen», bzw. Standard-Fragen welche noch nicht auf diesem Anlass hinzugefügt wurden defaultmässig als «versteckt» hinzuzufügen, wenn man den Anlass bearbeitet, würde das bedeuten:

• Alle bestehenden Anlässe werden bei der Migration nicht verändert. Alle Anmeldungen bleiben valid
• Alle bestehenden Anlässe erhalten beim ersten bearbeiten eine Kopie der Standardfragen, auch wenn eine gleiche/ähnliche Frage auf dem Anlass schon existiert, aber mit der Einstellung versteckt. Alle Anmeldungen bleiben valid
• Damit ist auch das Problem mit der Dauer der Migration gelöst

Was meinst du @richardjubla ? Wäre das für euch so akzeptabel?

Beim prüfen der bestehenden Anlässe und Fragen ist mir noch aufgefallen, dass es 244 Fragen ohne Fragetext gibt. Die führen dazu, dass die zugehörigen Anlässe ebenfalls nicht gültig sind.

[richardjubla]

Was meinst du @richardjubla ? Wäre das für euch so akzeptabel?

Wir haben getestet und die Kommunikation vorbereitet. Die Verantwortung für den Release, die Qualität und Auswirkungen inkl. Haftung auf das produktive System liegt explizit und abgesprochen mit @ThomasEllenberger bei euch.

[patriziajubla]

@diegosteiner

was mir gerade noch aufgefallen ist:

Bei einem Lager oder einem Anlass werden neue Fragen automatisch als Obligatorisch gesetzt inkl. Auswahlmöglichkeiten Optional, Obligatorisch, Nicht angezeigt - ich bin mir nicht sicher, ob dies gewünscht wird oder nur bei der Standardfrage der AHV

[diegosteiner]

Liebe @patriziajubla

Nein, es ist nicht vorgesehen, dass neue Standardfragen obligatorisch sind, sondern eben «nicht angezeigt». Hast du dies bei allen Lagern beobachtet oder nur bei diesem? Bist du sicher, dass es nicht bereits manuell auf «obligatorisch» gesetzt wurde? Sonst bitte ich dir mir auf der Integrationsumgebung Zugriff auf diese Schar zu geben, damit ich mir das ansehen kann. Danke für den Hinweis!

[patriziajubla]

@diegosteiner

du hast recht, die neue Frage war nicht obligatorisch, die Sterne bzw. das neue Layout haben mich verwirrt. Sowie das ich beim neuen Eintrag auch alle drei Optionen (Optional, Obligatorisch, Nicht angezeigt) zur Verfügung habe. Wieso sollte ich eine neue Frage erstellen und diese dann nicht anzeigen lassen. Hier handelt es sich um normale Fragen die ich pro Anlass erstelle und nicht um Standardfragen.

[diegosteiner]

Liebe @patriziajubla

Danke für die Rückmeldung. Das sehe ich ein, aber vielleicht gibt's ja trotzdem mal einen Fall, bei dem man eine Frage nicht mehr Anzeigen, die Antworten aber trotzdem behalten möchte. Das wäre dann möglich. Sonst könnte man schon darüber nachdenken, das «Nicht angezeigt» für eigene Fragen auszublenden.

[richardjubla]

Liebe @patriziajubla

Danke für die Rückmeldung. Das sehe ich ein, aber vielleicht gibt's ja trotzdem mal einen Fall, bei dem man eine Frage nicht mehr Anzeigen, die Antworten aber trotzdem behalten möchte. Das wäre dann möglich. Sonst könnte man schon darüber nachdenken, das «Nicht angezeigt» für eigene Fragen auszublenden.

@diegosteiner Die Möglichkeit des Setzen der Werte required und multiple_choices in event_questions.rb ist damit wohl nicht mehr möglich: https://github.com/hitobito/hitobito_jubla/pull/116/files

[ThomasEllenberger]

@diegosteiner Im SAC-Wagon erscheinen aktuell Antwortangaben ohne Frage. Da sie keinen Defaultwert hat, kam die Vermutung auf es könnte sich um die AHV-Frage handeln... Kannst du dir das evtl. einmal anschauen?

[richardjubla]

Als FG Datenbank möchten wir Scharen und Event-Veranstalter entlasten, dass sie nicht notwendige oder nicht legitimierbare Daten unbeschränkt aufbewahren. Dazu sollen die Antworten zu Events nach x Monaten automatisch gelöscht werden, damit dies der Vorstand oder die Event-Administration nicht manuell machen muss.

Wir beziehen uns auf hitobito/hitobito_sac_cas#367 und hitobito/hitobito_sac_cas#367

Vorgabe:

• Mit dem Release wird der Wert auf 5 Jahre (60 Monate) gesetzt und im Verband über die jubla.db (Release/Handbuch) kommuniziert. (Maximal rechtlich vertretbarer Nachweis für Event-Angaben). Mit einem folgenden Release soll der Wert dann auf 13 Monate gesenkt werden. (Damit haben die Scharen Zeit, allfällige Archiv-Wünsche oder spezielle Anforderungen abzudecken).

Vorgeschlagene Werte:

Settings.event.participations.delete_additional_information_after_months = 60
Setting.sevent.participations.delete_answers_after_months = 60

@ThomasEllenberger

Wir haben https://github.com/hitobito/hitobito_jubla/pull/120 versucht nachzuvollziehen. Aus meiner Sicht greifen die Anpassungen nicht auf dem produktiven System.

[ThomasEllenberger]

@richardjubla wir schauen uns das gerne noch einmal an. Hast du evtl. gerade ein Beispiel von einem Event welches älter als 5 Jahre ist, und bei dem die Anmeldeangaben noch gespeichert sind?

[richardjubla]

@richardjubla wir schauen uns das gerne noch einmal an. Hast du evtl. gerade ein Beispiel von einem Event welches älter als 5 Jahre ist, und bei dem die Anmeldeangaben noch gespeichert sind?

https://github.com/hitobito/hitobito_jubla/pull/120#issuecomment-2428756736