notify agents on RDV starting soon cancelled or date updated
Created by: adipasquale
Ce n'est pas super satisfaisant tel quel mais je ne sais pas s'il faut aller plus loin (cf pistes plus bas). Je m'appuie sur les callbacks ActiveRecord after_update
et sur la dernière version
stockée par papertrail pour trouver l'auteur du changement (sous forme textuelle uniquement eg "[Agent] Jean MARC" ou "[Usager] Pat OCHE").
J'ai extrait un concern Rdv::Notifiable
car la classe Rdv devenait trop longue pour le linter.
en passant, et j'ai du modifier deux choses sinon des erreurs apparaissaient sur les deliver_later
des mails de notifs de RDV qui disaient 'pas d'ID, impossible d'enqueue' :
- j'ai du changer le
after_create :notify_rdv_created
enafter_create_commit
. La différence est que le deuxieme s'effectue une fois la transaction commitée en DB. C'est effectivement ce qui est recommandé pour ce genre de callbacks qui interagit avec un systeme externe (ici la taskqueue). cf https://guides.rubyonrails.org/active_record_callbacks.html#transaction-callbacks - j'ai du changer lest
after_x :notify_x
enafter_x, -> { notify_x }
. c'est un fix un peu hacky pour contourner une limitation des callbacks AR : "Using both after_create_commit and after_update_commit in the same model will only allow the last callback defined to take effect, and will override all others.". J'ai trouvé ce contournement ici https://github.com/rails/rails/issues/29554#issuecomment-467837695 . une solution moins hacky mais vraiment peu explicite serait de faire un seul callback commun a tousafter_commit
et de brancher dans ce commit selon le cas effectif update / create + conditions
je suppose que c'est justement l'introduction d'un nouveau after_update_commit
qui fait que notre ancien équilibre ne tient plus et qu'il faut faire ces changements. Le 1. m'a l'air judicieux et pas vraiment un hack, mais le 2. est borderline, tu me diras ce que tu en penses @yaf. J'ai cependant ajouté des specs donc on devrait être avertis si ces callbacks arrêtent de se comporter comme on l'espère.
Autres pistes d'implémentation plus propres
notif lors de l'annulation
ca serait probablement plus simple, clair et evolutif avec une state machine pour le statut des RDVs. ça permettrait de déclencher des événements lors des transitions précises plutôt que se brancher sur le after_update
filtré selon les statuts avant après. Mais j'hésite a introduire cette state machine maintenant. je pense que c'est un petit chantier..
notif lors de l'update de date
je pense qu'il faudrait revoir l'UX pour que ce changement soit isolé du formulaire general de RDV, et que ça n'appelle pas la route rdv#update
mais peut etre une autre route plus précise genre rdv/reschedules#create
. On pourrait alors se brancher la et gerer plus explicitement selon la date du RDV avant et après update, et éventuellement en redonnant du contrôle à l'agent par ex avec une checkbox "prévenir les usagers".