Développement #65173
custom_user : ajout d’un champ de numéro de téléphone vérifiable
0%
Files
Related issues
Associated revisions
custom_user: perform implicit writes on redundant phone fields (#65173)
History
Updated by Paul Marillonnet over 2 years ago
- Related to Développement #49212: Création de compte avec un numéro de téléphone mobile added
Updated by Paul Marillonnet over 2 years ago
- Status changed from Nouveau to En cours
Commencé à pousser une ébauche et des bouts de test dans la branche, que je vais venir compléter dans les jours qui suivent.
Updated by Paul Marillonnet about 2 years ago
- File 0001-custom_user-add-phone-and-phone-verification-fields-.patch 0001-custom_user-add-phone-and-phone-verification-fields-.patch added
- Status changed from En cours to Solution proposée
- Patch proposed changed from No to Yes
La partie simple de #49212.
Updated by Benjamin Dauvergne about 2 years ago
- Status changed from Solution proposée to En cours
- Assignee set to Paul Marillonnet
On a gardé le booléen email_verified pour éviter des conséquence, mais là je pense qu'on peut se contenter d'un phone_verified = DateField() si c'est nul c'est qu'il n'est pas vérifié.
Je me pose la question de ce qui va se passer si on intègre ce patch et que le tenant a déjà un attribut nommé phone. Est-ce que comme pour first_name / last_name on prévoit une écriture implicite de l'un vers l'autre ? Est-ce qu'on migre les données existantes et on supprime l'attribut ? Est-ce qu'on prévoit dans ce cas une activation si un attribut nommé phone est activé coté hobo (ça veut dire modifier le hobo_deploy pour authentic pour traiter ce nom d'attribut spécifiquement) ?
Updated by Paul Marillonnet about 2 years ago
- Assignee deleted (
Paul Marillonnet)
Benjamin Dauvergne a écrit :
On a gardé le booléen email_verified pour éviter des conséquence, mais là je pense qu'on peut se contenter d'un phone_verified = DateField() si c'est nul c'est qu'il n'est pas vérifié.
Ok, fair enough.
Je me pose la question de ce qui va se passer si on intègre ce patch et que le tenant a déjà un attribut nommé phone. Est-ce que comme pour first_name / last_name on prévoit une écriture implicite de l'un vers l'autre ?
Oui, j’ai oublié cette partie et je crois que reprendre l’écriture implicite comme pour le nom et le prénom est la meilleure chose à faire.
Est-ce qu'on migre les données existantes et on supprime l'attribut ? Est-ce qu'on prévoit dans ce cas une activation si un attribut nommé phone est activé coté hobo (ça veut dire modifier le hobo_deploy pour authentic pour traiter ce nom d'attribut spécifiquement) ?
Et donc simplement je m’étais imaginé #69228, i.e. arrêter de créer l’attribut côté hobo, continuer de gérer l’écriture implicite notamment pour les instances déjà déployées. Dans le cas où la piste de #69228 serait retenue, l’activation se ferait simplement par un setting côté a2.
Je regarde pour corriger ce patch.
Updated by Paul Marillonnet about 2 years ago
- Assignee set to Paul Marillonnet
(Et foutus bugs de (dés)assignation automatique redmine.)
Updated by Paul Marillonnet about 2 years ago
- File 0002-custom_user-perform-implicit-writes-on-redundant-pho.patch 0002-custom_user-perform-implicit-writes-on-redundant-pho.patch added
- File 0001-custom_user-add-phone-and-phone-verification-fields-.patch 0001-custom_user-add-phone-and-phone-verification-fields-.patch added
- Status changed from En cours to Solution proposée
Les corrections mentionnées plus haut, notamment le seul champ de stockage de l’info de validation du numéro de téléphone, et avec l’écriture implicite du champ cœur phone vers un attribut de profil étendu du même nom, et vice-versa.
Je regarde côté hobo, si #69228 est jouable ou bien s’il faut procéder autrement.
Updated by Paul Marillonnet about 2 years ago
Paul Marillonnet a écrit :
Les corrections mentionnées plus haut, notamment le seul champ de stockage de l’info de validation du numéro de téléphone, et avec l’écriture implicite du champ cœur phone vers un attribut de profil étendu du même nom, et vice-versa.
Je regarde côté hobo, si #69228 est jouable ou bien s’il faut procéder autrement.
Et donc on est parti sur du phonenumbers avec une représentation E.164. #69228 bien faisable mais il y aura quand même un travail de migration des user.attributes.phone existant, c’est l’objet de #69365.
Updated by Benjamin Dauvergne about 2 years ago
- Status changed from Solution proposée to Solution validée
Ok.
Updated by Paul Marillonnet about 2 years ago
- Status changed from Solution validée to Résolu (à déployer)
commit d3e64bd82eaa7a08d204c301b3fb22db4f6a95b6 Author: Paul Marillonnet <pmarillonnet@entrouvert.com> Date: Mon Sep 19 14:23:40 2022 +0200 custom_user: perform implicit writes on redundant phone fields (#65173) commit 34215788c5d6e17ddf06c1345920f0d391a58bcb Author: Paul Marillonnet <pmarillonnet@entrouvert.com> Date: Mon Sep 19 08:54:02 2022 +0200 custom_user: add phone and phone verification fields (#65173)
Updated by Transition automatique almost 2 years ago
- Status changed from Résolu (à déployer) to Solution déployée
custom_user: add phone and phone verification fields (#65173)