Les RdvUser sont, à l’origine, la table de jointure entre Rdv et User; on se rend compte qu’elle est importante en elle-même. Elle contient actuellement:
send_lifecycle_notifications et send_reminder_notification, les flags permettant de préciser si les notifications sont à envoyer à un usager pour un Rdv particulier;
invitation_token et tous les attributs de Devise pour permettre l’accès à un Rdv particulier (cf #2384)
Ça a aussi un impact sur ce qu’on veut en faire sur le code:
L’annulation d’un Rdv annule le Rdv pour tout le monde: c’est gênant pour les Rdv collectifs #2400
Dans le même style, pour les Rdv Collectifs, on ne peut pas savoir si certains utilisateurs sont venus, et pas d’autres (cf #2235).
Alternativement, on peut supprimer un RdvUser, mais alors on n’a plus aucune trace de l’ancienne Participation. C’est la raison pour laquelle les Receipts sont associés à la fois à un Rdv et à un User, mais pas au RdvUser.
Enfin, il y a actuellement tout un mécanisme complexe autour des responsables pour savoir qui notifier et à quelle adresse à lieu le Rdv, dans le cas ou le Rdv est pris pour un usager proche d’un responsable.
Renommer RdvUser, modèle et classe, en Participation.
Donner un “niveau de participation” au Rdv, selon son implication.
Associer tous les usagers concernés aux Rdv, proches et responsables. Ainsi, les proches sont directement liés au Rdv dès le début, et il n’y a plus besoin de recalculer à qui envoyer les notifs à chaque fois. (Devrait fonctionner avec adaptation même si c'est fait après #1670)
Permettre l’annulation et le changement d’état par participation.
Réécrire les Notifiers et les Mailers; je pense que ça supprime pas mal de chose, par exemple il n’y a plus besoin de users_to_notify, et on peut passer la Participation à Users::RdvMailer.
À vue de nez, la Participation permet d’exprimer:
une convocation au Rdv (c’est-à-dire, si le Rdv est pour lui ou elle)
une observation pour notification, dans le cas par exemple d’un parent qui prend Rdv pour son enfant (l’enfant est convoqué, le parent est notifié)
un état qui reprend les états actuels de rdv: “attendu”, “vu”, “excusé”, “révoqué”, “lapin”.
%i[unknown seen excused revoked noshow] en VO. Je passe sous silence waiting, et il y a aussi une notion de participation “notifié simplement pour observation”.
ferme #2137
C’est un peu plus que renommer la table.
Les
RdvUser
sont, à l’origine, la table de jointure entreRdv
etUser
; on se rend compte qu’elle est importante en elle-même. Elle contient actuellement:send_lifecycle_notifications
etsend_reminder_notification
, les flags permettant de préciser si les notifications sont à envoyer à un usager pour un Rdv particulier;invitation_token
et tous les attributs de Devise pour permettre l’accès à un Rdv particulier (cf #2384)Ça a aussi un impact sur ce qu’on veut en faire sur le code:
users_to_notify
, et on peut passer la Participation àUsers::RdvMailer
.À vue de nez, la Participation permet d’exprimer:
%i[unknown seen excused revoked noshow]
en VO. Je passe sous silencewaiting
, et il y a aussi une notion de participation “notifié simplement pour observation”.