[FEATURE] - Late Unregistrations Handling

[o-rayer]

Feature aiming at reducing the number of late unregistrations to events

https://trello.com/c/kDRVotJB/294-features-pour-r%C3%A9duire-les-d%C3%A9sinscriptions-sauvages

Functional Schema

• An Unregistration is considered late if the event has a required activity (ex : collectives) and if the user unregisters less than 48h prior to the Event starting time

Key Features

• Leverages the Badges logic to assign 3 types of Badges : FirstWarning, SecondWarning & Banned
• FirstWarning, SecondWarning expire the next 30th of September
• Banned expires 4 weeks after assignment
• When a user has a valid Banned badge, he cannot register to an event
• Badge assignment priority is given to the lowest badge (First > Second > Ban)
• 'Se Désinscrire' button now has a proper pop-up screen instead of a flash, personalized if is it whether a late unsubscription or not
• When unregistering lately, an warning or banishment email is sent to the user, according to its warning level
• An Admin can manage badges and can handle banishment if required
• Stats module has a new line chart following Unregistrations, LateUnregistrations & UnjustifiedAbsentees per week over the last 52 weeks

Things to review or determine in priority

• The whole functional logic
• Transition table possibilities for late unregistrations
• Multi-day events unregistration
• All mails & pop-up contents
• If mailing fails, the logic should still work

Next ideas / Things to do

• Leader actions : transition by a from “LateSelfUnregistered” to “Active” should remove the latest Warning Badge assigned (by default the most valid & restrictive one)
• Leader actions : Unjustified Absentees should be handled in the Ban logic
• Leader actions : Could excuse a LateSelfUnregistered user remove and latest Warning Badge assigned (by default the most valid & restrictive one)
• Leader actions : remove latest Warning Badge assigned (by default the most valid & restrictive one) to "registered" users if an event is cancelled last minute
• Unregistering to Multi-days events should be considered late 7 days before event start (and not 48h)
• A User should see somewhere the remaining banishment time (account suspension) or the number of warnings issues or remaining
• Mailing functional testing
• Rationalize tests using proper factories to generate users, events etc...
• Add a last_unregistration_time or last_self_unregistration_time to the Registration object in order to follow unregistration properly in the stats module

[bbouffaut]

Je suis assez en phase avec le fait d'utiliser le level du badge dans les 2 cas, tout en étant bien conscient de la limitation que tu mentionnes Aurélien. Merci bcp pour ce travail en tous cas !!

On Tue, Feb 27, 2024 at 8:28 AM Aurélien Rayer @.***> wrote:

@.**** commented on this pull request.

In collectives/models/badge.py https://github.com/Club-Alpin-Annecy/collectives/pull/683#discussion_r1503755307 :

@@ -21,6 +34,9 @@ def display_names(cls): """ return { cls.Benevole: "Bénévole",

• cls.FirstWarning: "Désinscription Tardive - 1er avertissement",
• cls.SecondWarning: "Désinscription Tardive - 2ème avertissement",

J'y ai pensé aussi @gdaviet https://github.com/gdaviet tu as raison ce serait plus propre.

Le seul truc qui m'embête c'est que d'un côté on utiliserait le level pour le comptage (Banned) et de l'autre pour une logique fonctionnelle ( warning) + il faudrait accepter qu'on n'ait jamais besoin de compter le nombre de warnings, et il faut revoir la logique d'update. Ca peut le faire pour moi.

A confirmer tous ensemble ?

— Reply to this email directly, view it on GitHub https://github.com/Club-Alpin-Annecy/collectives/pull/683#discussion_r1503755307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB32XJF3TQMSMVKB56UYVUDYVWDJHAVCNFSM6AAAAABDGKFG7GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMBSG4YTINRUGQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>