Notifications fines par rendez-vous (1/N): Modèle et logique
Created by: n-b
refs #1617 (closed), reprise de #1742
Fait dans cette PR:
-
Renommage et refactor des “services” de notification. C’est sans lien direct avec le problème, si ce n’est que ce sont les mêmes fichiers. Au passage, je transforme Notifications::Rdv::BaseServiceConcern
en véritable classe intermédiaire; je ne tiens pas à l’héritage, mais on avait déjà cette hiérarchie dans les faits, sans le dire. Pour cette raison, la PR est un peu grosse, mais ça se lit bien commit par commit. -
Nouveaux flags send_lifecycle_notifications
etsend_reminder_notification
sur RdvUser, avec migration des anciennes données. Ces flags sont non-null en base. -
Affectation automatique de la valeur des flags à la création d’un Rdv à partir du visibility_type
du Motif. -
Prise en compte des flags dans les services de notification.
Reste à faire dans les PR suivantes:
- Choix par l’agent à la création du Rdv
- Affichage des valeurs des flags dans rdv#show et rdv#edit
Et éventuellement:
- Je renommerais bien
RdvUser
enParticipation
ouUserParticipation
, qu’en pensez-vous? - Ça simplifierait l’évolution à venir sur les notifications multiples et les usagers simples “observateurs” d’un Rdv (#1670) On rajouterait alors un flag à
UserParticipation
pour indiquer si l’usager est convoqué au Rdv, et on n’aurait plus besoin de se baser sur la relation de responsable.
Checklist avant review:
-
reparcourir le code rapidement pour voir les problèmes évidents (fichiers touchés inutilement, debug logs qui trainent…). -
Tester la fonctionnalité sur la review app