Project

General

Profile

Bug #80950

API: un attribut nommé phone n'est plus mis à jour

Added by Benjamin Dauvergne 11 months ago. Updated 10 months ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
06 September 2023
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Depuis le patch du ticket #79135 lors d'une mise à jour par web-service du numéro de téléphone, si l'attribut se nomme phone seul la colonne User.phone est mise à jour et pas l'attribut lui même. Je suppose parce qu'il y a collision au niveau de authentic2.api_views.BaseUserSerializer entre le champ DRF créé pour User.phone et le champ DRF créé pour l'Attribut du même nom.

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


Related issues

Related to Authentic 2 - Development #79135: custom_user : déprécier le champ de base User.phoneFermé27 June 2023

Actions
Related to Authentic 2 - Development #81282: Retrait de la colonne User.phoneEn cours18 September 2023

Actions

Associated revisions

Revision 704c085b (diff)
Added by Paul Marillonnet 10 months ago

api: write user's phone as a profile attribute only (#80950)

History

#2

Updated by Benjamin Dauvergne 11 months ago

  • Subject changed from L'attribut phone n'est plus mis à jour to API: un attribut nommé phone n'est plus mis à jour
  • Description updated (diff)
#3

Updated by Paul Marillonnet 11 months ago

  • Status changed from Nouveau to En cours
#4

Updated by Paul Marillonnet 11 months ago

  • Related to Development #79135: custom_user : déprécier le champ de base User.phone added
#5

Updated by Paul Marillonnet 11 months ago

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)

#6

Updated by Robot Gitea 11 months ago

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

#7

Updated by Robot Gitea 10 months ago

  • Status changed from En cours to Solution proposée
#8

Updated by Benjamin Dauvergne 10 months ago

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...

#9

Updated by Paul Marillonnet 10 months ago

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

#11

Updated by Benjamin Dauvergne 10 months ago

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.

#12

Updated by Paul Marillonnet 10 months ago

  • Status changed from Solution proposée to En cours

Ok, fair enough, je vais retirer le champ de l’API, je me garde cette PR ci sous le coude pour un futur ticket de retrait complet de la colonne.

#14

Updated by Paul Marillonnet 10 months ago

#15

Updated by Robot Gitea 10 months ago

  • Status changed from En cours to Solution proposée
#16

Updated by Robot Gitea 10 months ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#17

Updated by Robot Gitea 10 months ago

  • Status changed from Solution validée to Résolu (à déployer)

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

#18

Updated by Transition automatique 10 months ago

  • Status changed from Résolu (à déployer) to Solution déployée
#19

Updated by Transition automatique 8 months ago

Automatic expiration

Also available in: Atom PDF