You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Une partie importante de ces erreurs arrive avec un referer de /users/user_name_initials_verification/new, cf cette requête Sentry Discover.
Il me semble que cette route n’intervient que pour les invitations émises par RDVI.
Actuellement
Comportement actuel : si je crée un RDV pour un motif "invisible" et que j'active pour ce RDV les notifications (de création / modif ou de rappel), l'usager reçoit des notifs contenant un lien vers le RDV, qui le mène à une 404 car le RDV est invisible.
Étapes pour reproduire cette situation :
Créer un motif en définissant le paramètre "Visibilité usager" sur "Invisible"
Créer un RDV avec ce motif, et à l'étape "Notifications", cocher "Notifications de création et modification"
Ouvrir le mail de notification envoyé à l'usager pour l'informer que le RDV a été créé
Cliquer sur le lien "Annuler ou modifier le rendez-vous" puis saisir les initiales
Constater qu'on arrive sur une page 404
Objectif
Solutions possibles :
ne pas envoyer de notifications
ne pas inclure le lien dans les notifications si le RDV est invisible
afficher le RDV si on y accède via un lien, même si il est invisible dans la liste des RDVs du commpte de l'usager
Je me permets de rajouter un peu de contexte produit / métier côté rdv-insertion :
Pour info, on a récemment fait une communication à toutes nos organisations qui faisaient de la convocation en expliquant qu'il était préférable de mettre les motifs de convocation en "Invisible", sinon quoi les usagers recevaient une double notif rdv-insertion / RDV Solidarités.
Si la consigne selon laquelle il ne faut pas re-cocher "Notifications de création et modification" lors de la création du rendez-vous est désormais bien connue des responsables d'équipe / admin des orgas, je pense que certains professionnels qui positionnent des rendez-vous ne l'ont pas clairement en tête et continuent de re-cocher cette case ➡️ ce qui demeure donc confusant pour l'usager qui reçoit deux motifs et, je l'apprend dans ce ticket, assez embêtant en raison de la 404 qu'il a en cliquant sur la notification RDV S. Ne pas envoyer du tout de notification RDV S dans ce cas de figure aiderait donc beaucoup à notre usage je pense.
Le comportement incohérent décrit ici a été découvert en investiguant les 404 qui remontent sur le RDV#show des usagers : https://sentry.incubateur.net/organizations/betagouv/issues/126102
Enquête
Une partie importante de ces erreurs arrive avec un referer de
/users/user_name_initials_verification/new
, cf cette requête Sentry Discover.Il me semble que cette route n’intervient que pour les invitations émises par RDVI.
Actuellement
Objectif
Solutions possibles :
Technique
L'invocation de la policy d'accès aux RDVs est faite ici :
https://github.com/betagouv/rdv-solidarites.fr/blob/22ff2b0e05ba1b66b607b9edd0993f82c4344628/app/controllers/users/rdvs_controller.rb#L109
The text was updated successfully, but these errors were encountered: