Produits Entr'ouvert » Authentic 2

Commencé à pousser une ébauche et des bouts de test dans la branche, que je vais venir compléter dans les jours qui suivent.

La partie simple de #49212.

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) ?

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.

(Et foutus bugs de (dés)assignation automatique redmine.)

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.

Ok.

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)