Kursadministration - Saisonstart November

[richardjubla]

Dieses Issue beschreibt die Bedürfnisse der Kursadministration

Story Als Kursadmin auf Ebene Verband und Kantone, möchte ich meine Kurse erfolgreich auf der jubla.db ausschreiben können. Wir haben viel Zeit in eigene Test und die Beschreibung von Fehlern investiert. Nun möchten wir auf den Start der Kurs-Saison ab November 2023 die Unterscheide zwischen Stage-/Produktivumgebung und dem notwendigen Release dazwischen so weit wie möglich abfangen, damit bei ca. 35 offenen Kursen mit über 300 Teilnehmenden bis zu 3'000 Kursanmeldungen zu bewältigen sind.

Wir gehen von folgenden (zwingenden) Anforderungen aus:

• [ ] Für einen Kurs muss festgelegt werden können, dass eine automatische Zuteilung (definitive Anmeldung) nur manuell durch die Kursadministartion erfolgen kann. So können wir verhindern, dass definitive Anmeldungen (Anmeldebestätigung) mit fehlenden Vorbedingungen, Anmeldungen ohne Unterschrift oder fehlenden Freigaben (durch Scharleitung) erfolgen. Auf der Produktivumgebung haben wir dafür die Option "event_supports_applications" verwendet. Als Workaround würden wir die "Maximale Teilnehmerzahl" (event_maximum_participants) auf 0 setzten und deren Sichtbarkeit (event_display_booking_info) verhindern. Damit werden alle Anmeldungen nicht direkt Zugeteilt.
• [ ] Die Anmeldung an einen Kurs muss mit der Option "Freigabe: Die Scharleitung wird informiert und muss die Anmeldung bestätigen" (event_requires_approval) eingeschränkt werden können. Muss die Scharleitung die Anmeldung bestätigen muss dieser Prozess in der jubla.db/hitobito möglich sein und funktionieren. Siehe: https://github.com/hitobito/hitobito/issues/2120
• [ ] Explizit muss im Prozess der Kursfreigabe (event_requires_approval) die E-Mail/Transaktionsmail versendet werden. Ohne diese E-Mail gehen die Anmeldungen vergessen und müssen mit grossem Aufwand koordiniert werden. Als Workaround müsste in der Voranmeldung (E-Mail/Kursbeschrieb) klar kommuniziert werden, dass der Scharleiter den Kurs-Link erhalten muss und dort die Anmeldung bestätigen muss.

Aspekte

• Anpassungen am Core / Probleme nach Update durch Cevi
• Lösung NUR für Jubla, da uns nicht klar ist oder klar gemacht wurde, wie und wo (core, youth, jubla) welche Funktionen sind

Relevante Tickets https://github.com/hitobito/hitobito_jubla/issues/47 https://github.com/hitobito/hitobito/issues/2122 https://github.com/hitobito/hitobito/issues/2120 https://github.com/hitobito/hitobito_jubla/issues/54 https://github.com/hitobito/hitobito_jubla/issues/55

Definition of Done:

• Das Kurswesen wurde soweit geflickt, getestet und abgenommen damit es weiterhin produktiv eingesetzt werden kann.
• Die Lösung ist so beschreiben und nachvollziehbar, dass sie von Menschen auf der Stage-/Produktivumgebung getestet und ohne Code-/Programmierkenntnisse nachvollzogen werden kann.
• Ein klarer Zeitplan liegt vor

[richardjubla]

Puzzle: Bei Issue Jubla#58 gehen wir davon aus, dass das Flag zum Mailversand an Scharleiter einfach nur aktiviert/deaktiviert ob Mails versendet werden, sonst jedoch keine Logik ändert (Also nicht bei Aktivierung Anmeldung nur provisorisch angemeldet werden, o.ä.) sondern dies entsprechend durch die anderen Einstellungen gegeben wird.

Gemäss meiner Information und anhand unserer Anleitung gibt/gab es bereits ein versendetes E-Mail. Wir benötigen, dass im Prozess der Kursfreigabe (event_requires_approval) die E-Mail/Transaktionsmail (wieder) versendet werden. Akutell scheint dies weder auf der Stage- noch auf der Produktivumgebung der Fall zu sein.

[richardjubla]

Rein als Dokumentation und Erinnerung zu diesem Thema und nicht als Bestandteil des Issue:

Version 1.28.30.2 Aktivieren und Deaktivieren der Option "Verwendet Warteliste" (event_supports_applications) lässt Anmeldungen "verschwinden" und führt zu Fehlermeldungen. Der Status der Anmeldungen geht dabei verloren da sie wohl weder zugeteilt noch in der Warteliste sind. Ein Aufruf der Anmeldungen führt dann zu einer Fehlermeldung (E500).

[richardjubla]

Story Issue wird geschlossen, da organisatorisch das Ziel nicht erreicht werden konnte. Die Bedürfnisse sind weiterhin "korrekt" und können bei entsprechender Priorisierung durch jubla wieder aktiviert werden.