Création d'un deuxième compteur "épargne"

[raphodn]

(ébauche. à détailler)

Quoi ?

L'idée est de pouvoir séparer le compteur du membre en 2 :

• un compteur-temps "courant" qui enlève 3h (due_duration_by_cycle) à chaque cycle
• un compteur-temps "épargne" qui permette au membre de faire du bénévolat supplémentaire

Pourquoi ?

Un nouveau règlement intérieur a été voté à l'Elefan à l'automne 2022. Il permet d'avantage de flexibilité dans la réservation et l'annulation des créneaux par les membres.

Ce double compteur permettra de résoudre plusieurs problèmes :

• la non prise en compte du bénévolat facultatif (actuellement, les compteurs sont remis à 0 à la fin de chaque cycle)
• permettre aux membres de mieux s'organiser d'un cycle à un autre, pour prendre des vacances ou annuler des créneaux qu'ils ne peuvent pas faire sans pénalités

Comment ?

• soit utiliser l'objet TimeLog existant (avec type = "épargne")
• soit créer un nouvel objet

aussi

• lorsqu'on libère un créneau dans le passé, ca ne devrais pas supprimer de la table TimeLog : au contraire on rajoute un timelog négatif pour compenser : Lors d'actions sur les créneaux passés, ne pas supprimer les TimeLog correspondants #704
• modifier l'action "régulation bénévolat facultatif"
• aller piocher dans le compteur épargne

[raphodn]

Implémentation (après discussion avec @symartin @petitalb)

Compteur épargne

des lignes TYPE_SAVING dans l'entité TimeLog

Cas d'usage

Créneau fait en rab

Comment savoir si un créneau est "en rab" ? Regarder le nombre de créneaux déjà validés dans le cycle courant.

Cela rajoute 3 lignes à TimeLog

• 1 ligne SHIFT_VALIDATED incrémenter le compteur-temps (comme actuellement)
• 1 ligne TYPE_REGULATE_OPTIONAL_SHIFTS pour envoyer la durée du shift du compteur-temps vers le compteur-épargne (négatif)
• 1 ligne TYPE_SAVING pour incrémenter le compteur-épargne (positif)

L'utilisateur annule un créneau prévu

Possible seulement si le compteur-épargne est positif (et supérieur à la durée du créneau en question).

Cela rajoute 1 ligne à TimeLog

• 1 ligne TYPE_SAVING pour décrémenter le compteur-épargne (négatif)
• 1 ligne ? pour incrémenter le compteur-temps (positif)

A la fin du cycle

On enlève Xh comme d'habitude.

• le bénévolat facultatif a été régulé au fil de l'eau. Donc pas de régulation nécessaire.
• si le membre n'a pas fait de créneau, on prend depuis le compteur épargne (et si vide ou insuffisant, on prend le reste depuis le compteur temps)
• cas particulier : si le membre n'est pas venu à un créneau programmé, on prend depuis son compteur temps (et non épargne)

Pour finir

• faire des PR et merger sur une branche séparée ? Non mieux : ajouter un parametre pour activer ou pas ce fonctionnement !

Question en suspens

• quid d'un admin qui souhaite annuler la participation à un créneau, on enlève du compteur-temps ou du compteur-épargne ? lui donner le choix ?
• quoi faire si on invalide un créneau déjà validé ?
• quid d'un créneau en fin de cycle non validé, et qui sera validé lors du cycle suivant : cas trop particulier, les membres n'ont qu'à badger..

[raphodn]

TODO

• nouveau paramètre use_time_log_saving
• nouveau TimeLog type TYPE_SAVING
• onShiftValidated : incrémenter le compteur épargne si due_duration_by_cycle dépassé
• onMemberCycleEnd : (à compléter)
• Membership.getTimeCount : ne pas prendre en compte TYPE_SAVING dans le calcul du compteur temps
• SearchUserFormHelper : ne pas prendre en compte TYPE_SAVING dans le calcul du compteur temps
• Affichage basique dans l'onglet "Compteur de temps"
• Affichage basique dans la home de l'utilisateur

Annulation de créneau

voir #686

• onShiftFreed : vérifier que le membre peut bien annuler son créneau (v1) + décrémenter le compteur épargne + incrémenter le compteur temps
• Règles avancées sur l'annulation de créneau : 10 jours à l'avance, orienter vers le BDM sinon
• Annulation d'un créneau coté admin : lui donner le choix d'utiliser ou nom le compteur épargne ?

Optimisations à faire dans un second temps

• améliorer les calculs des TimeCount : remplacer les for loops par des queries SQL (via un TimeLogRepository)