Ajout du champ notification_email pour les usagers, modifiable uniquement via l'api (par rdv-insertion)
#5003
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ultiple user with same email
Holist
commented
Jan 28, 2025
| @@ -6,6 +6,8 @@ class UserBlueprint < Blueprinter::Base | |||
| :notify_by_email, :invitation_created_at, :invitation_accepted_at, :created_at, :case_number, :address_details, | |||
| :logement, :notes | |||
|
|
|||
| field :notification_email, if: ->(_field_name, _user, options) { options[:include_notification_email] } | |||
There was a problem hiding this comment.
A voir si on ne souhaite pas conditionner de cette façon, on pourrait toujours afficher le champ si il est rempli par exemple.
|
|
||
| def change | ||
| add_column :users, :notification_email, :string | ||
| add_index :users, :notification_email, algorithm: :concurrently |
There was a problem hiding this comment.
Un index partiel (WHERE NOT NULL) mer semble très judicieux ici !
| @@ -90,6 +91,11 @@ def email=(value) | |||
| super(value&.gsub(".@", "@")&.gsub("..", ".")) | |||
| end | |||
|
|
|||
| def notification_email=(value) | |||
| # On applique les mêmes corrections pour notification_email | |||
| super(value&.gsub(".@", "@")&.gsub("..", ".")) | |||
There was a problem hiding this comment.
Je pense qu'on peut factoriser dans une méthode de classe du genre .sanitize_email(email) puis appeler super(sanitize_email(value))
Comment on lines
-56
to
+58
| attrs -= User::FranceconnectFrozenFieldsConcern::FROZEN_FIELDS if @user&.logged_once_with_franceconnect? | ||
| # Seul rdv-insertion peut enregistrer l'email de notification des usagers | ||
| # Celui ci permet de notifier plusieurs usagers avec le même email | ||
| base_attrs << :notification_email if rdvinsertion_request? |
There was a problem hiding this comment.
Je trouve ça étonnant qu'on ait un champ uniquement dispo à RDV-I dans notre API publique. Quel est le risque de rendre ce champ utilisable par n'importe qui ?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes gip-inclusion/rdv-insertion#2065
Contexte
Nous avons besoin de pouvoir assigner à différents usagers le même email de notification lors de la création des comptes pour les invitations à prendre rdv dans rdv-insertion dans le cas d'un couple conjoint demandeur RSA ou dans le cas d'un déménagement (plusieurs comptes seront créés sur les différents territoires).
Un début d'implémentation avait été réalisé en septembre dernier ici et ici. Il n'a pas été poursuivi car cela avait des répercussions trop importantes, notamment le renommage du champ
emailenaccount_email.Suite à cela une spec fonctionnelle et technique a été réalisée pour évaluer les options possibles.
Une discovery a été mené par @NesserineZarouri à ce sujet pour identifier les besoins coté RDVSP.
Il en est ressorti qu'il n'y a pas de besoin de cette fonctionnalité aujourd'hui coté RDVSP.
On a donc décidé de choisir l'implémentation minimale de la fonctionnalité tout en pouvant évoluer si besoin.
Solution
On ajoute le champ
notification_emailpour les usagers.Ce champ est modifiable uniquement via l'api et seulement pour les clients qui utilisent le shared secret (uniquement rdv insertion).
Dans le front on affiche l'email de notification dans la show de l'usager si celui ci existe pour que les agents rdvi connectés à rdvsp puissent avoir l'information.
Dans l'edit du formulaire de l'usager il n'y a pas de changement. Si un email est renseigné celui ci prendra la valeur du champ
emailet un callback effacera le champnotification_emailde l'usager.Les mailers sont modifiés pour utiliser l'email ou le notification_email en fonction de celui qui est rempli.
Techniquement
J'ai hésité à ajouter de nouveaux endpoint create et update au
Api::Rdvinsertion::UsersController. Au final j'ai préféré modifierApi::V1::UsersControllerafin d'éviter de la duplication de code qui pourrait poser problème si on doit un jour mettre à jour ces méthodes.