Produits Entr'ouvert » Authentic 2

Benjamin Dauvergne a écrit :

Il faudrait reverter #79135 en attendant de pouvoir remettre les bases d'équerre. Plus simplement supprimer le champ phone de BaseUserSerializer.

Peut-être même complètement supprimer User.phone ? (Après avoir écrit la migration qui va en copier la valeur vers User.attributes.phone si celle-ci n’y est pas renseignée)

Paul Marillonnet (pmarillonnet) a ouvert une pull request sur Gitea concernant cette demande :

• URL : https://git.entrouvert.org/entrouvert/authentic/pulls/125
• Titre : WIP: dépréciation du champ de téléphone du modèle utilisateur, suite (#80950)
• Modifications : https://git.entrouvert.org/entrouvert/authentic/pulls/125/files

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Il faudrait reverter #79135 en attendant de pouvoir remettre les bases d'équerre. Plus simplement supprimer le champ phone de BaseUserSerializer.

Peut-être même complètement supprimer User.phone ? (Après avoir écrit la migration qui va en copier la valeur vers User.attributes.phone si celle-ci n’y est pas renseignée)

1. Je ne vois pas comment savoir par défaut quelle est la bonne valeur, si ça a été mis à jour via web-service, c'est bien User.phone qui a la dernière valeur mais si c'est via la page mon compte, c'est l'attribut je pense.
2. Ta migration va être très lente, itérer sur parfois 100000 utilisateurs...

Benjamin Dauvergne a écrit :

1. Je ne vois pas comment savoir par défaut quelle est la bonne valeur, si ça a été mis à jour via web-service, c'est bien User.phone qui a la dernière valeur mais si c'est via la page mon compte, c'est l'attribut je pense.
2. Ta migration va être très lente, itérer sur parfois 100000 utilisateurs...

Je vais faire un ticket lié pour avoir des stats pour chaque instance concernant les usagers sujets à cette divergence, qu’on comprenne à quel point 1. et 2. sont bloquants.

Comme je disais dans la PR gitea liée, pour les instances problématiques il faut traiter au cas par cas. La PR ici se veut proposer une approche générale, une fois les cas problématiques évacués, pour ne pas conserver User.phone et User.attributes.phone en concurrence ad vitam æternam (et ne pas s’exposer à nouveau à des soucis de divergence décrits dans ce ticket).

Je ne trouve pas le déroulé idéal, je préférerai mettre tout de suite les instances dans un état qui fonctionne, et notamment l'instance de Toulouse qui m'intéresse un peu, par exemple en retirant explicitement le champ de l'API et/ou en rétablissant la synchro, pour que le formulaire de modification des comptes d'AlloToulouse fonctionne. Ensuite on peut corriger les données et au final on pourra retirer la colonne qui contiendra forcément des données en doublon.

Automatic expiration