Mise en place d'un champ `contact_email` pour les usagers

[Holist]

ℹ️ Contexte

Le contexte détaillé se trouve ici :
gip-inclusion/rdv-insertion#2065

En résumé, nous avons la possibilité dans RDVI de créer des couples demandeur/conjoint qui partagent souvent le même email (et adresse et numéro de tél).
Dans RDVSP le demandeur est créé avec l'email renseigné (dans le champ classique email). Le conjoint est créé sans email et on lui demande de renseigner un email lors de la prise de rdv par invitation.

❓ Définition du problème

Ce système pose plusieurs problèmes dans le matching des usagers avec RDVSP. En effet si le couple demandeur/conjoint n'est pas bien défini la contrainte d'unicité sur l'email dans RDVSP bloque la création des usagers depuis RDVI.
Cela empêche également le conjoint de prendre son rdv si il cherche à renseigner l'email du couple dans le formulaire précédent (email déjà pris par le demandeur).

💡 Solution envisagée

Une solution potentielle (à discuter dans cette issue) serait de mettre en place un champ contact_email sans contrainte d'unicité donc et qui serait le champ privilégié par RDVI pour la création des usagers et pour les notification dans RDVSP.
Techniquement il n'y a pas vraiment de difficultés à mettre cela en place (on pourrait imaginer par exemple une modification du default to: -> { @user.email } en @user.notification_email qui utiliserait le nouveau champ contact_email si il est défini avec un fallback sur l'email classique de devise si il ne l'est pas).
On pourrait enlever l'obligation de renseigner l'email lors de la prise du rdv. Cela signifierai que l'usager n'a pas de compte RDVSP et pourra accéder à ces rdvs uniquement via les liens d'invitation.

Cela pose des questions d'implémentation et de produit.

• Est ce que ce principe serait généralisé ou uniquement mis en place via l'api lors de la création des usagers par RDVI dans un premier temps ?
• Est ce que ce système pourrait matcher certains besoin coté RDVSP (coté interop usager par exemple ?)
• Si on décide de rendre ce champ modifiable/accessible aux agents, que faisons nous des formulaires usagers dans lesquels on renseigne aujourd'hui le champ email classique ?

🧪 Inconvénients

il faudra être prudent car cela touche aux notifications usagers qui sont au coeur de l'application.

[victormours]

Oui ! Ça serait très utile de pouvoir distinguer le contact_email (l'adresse mail à laquelle envoyer des notifications), du account_email (l'adresse mail utilisée par l'usager pour se connecter à son compte). Ça nous simplifierait énormément de choses du côté médico-social où on a ces mêmes problèmes d'adresse mail commune.
Ça nous éviterait d'aussi de devoir faire du dédoublonnage inter-territoires sur les adresses mail, ce qui sera une très bonne chose pour la conformité RGPD

[Holist]

Super !
Amine a également suggéré si on part la dessus de renommer le champ email devise en account_email, ce qui pourrait être une première étape.
Concernant la création d'un usager et les formulaires d'édition usager qui contiennent actuellement le champ email, l'idée serait de modifier ce champ et d'utiliser le contact_email uniquement en laissant l'usager gérer lui même son account_email ? (qui dans 80% des cas sera identique j'imagine)
D'après toi quels seraient les autres chantiers liés à ce changement ? Comme tu l'as suggéré on pourrait aussi revoir la politique de dédoublonnage de rdvsp (cela pourrait se faire une fois le nouveau champ contact_email mis en place).

[victormours]

Discuté en visio :

• pour le moment avoir deux colonnes notification_email et account_email, et une règle de validation qui permet qu'on ai soit l'un soit l'autre mais pas les deux en même temps
• garder une méthode email qui renverra notification_email || account_email
• permettre d'avoir des doublons de notification_email
• les emails manipulés par les agents sont les notification_email, ceux manipulés par les usagers sont les account_email. Le account_email a la priorité sur le notification_email (i. e. l'agent ne peut pas modifier l'email d'un usager si c'est sont account_email). Au moment où l'agent invite l'usager à se créer un compte sur rdv solidarités, il faut qu'on remplisse le account_email avec le notification_email.