Projet

Général

Profil

Bug #7085

don't reuse django username field for name id

Ajouté par Frédéric Péters il y a presque 9 ans. Mis à jour il y a plus de 8 ans.

Statut:
Fermé
Priorité:
Haut
Assigné à:
Version cible:
-
Début:
29 avril 2015
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

It's commonly limited to 30 characters while a UUID is 32 characters, final.


Fichiers

Révisions associées

Révision 86a1167b (diff)
Ajouté par Benjamin Dauvergne il y a presque 9 ans

add a model to store user<->NameID mapping (#7085)

Révision 1f56211c (diff)
Ajouté par Benjamin Dauvergne il y a presque 9 ans

Limit username to 30 characters for now (#7085)

Historique

#1

Mis à jour par Benjamin Dauvergne il y a presque 9 ans

First patch add a model to store name_id to user mapping and add a new lookup method using it. The old lookup method still exist but as a failover.

To completely disactivate the old lookup method you can add MELLLON_LOOKUP_METHODS = ['name_id'] to the settings,py file.

The second patch truncate formatted username to 30 characters before filling the user.username field with it, so that the default username template do not break anything whatever is put in the NameID.

#2

Mis à jour par Benjamin Dauvergne il y a presque 9 ans

  • Patch proposed changé de Non à Oui
#3

Mis à jour par Frédéric Péters il y a presque 9 ans

What about migrating existing accounts so there's no MELLLON_LOOKUP_METHODS but a single way to find the user?

#4

Mis à jour par Benjamin Dauvergne il y a presque 9 ans

For us there will be no such case where the old method will be used, as there is no production deployment of django_mellon (event at the Wallon parliement it's not activated), so I could just remove the old lookup method. I just kept it to prevent breaking current test and dev environment as much as possible.

#5

Mis à jour par Frédéric Péters il y a presque 9 ans

I much prefer code in migrations, easy to forget, than adding code that will have to maintained and tested and will be broken because that's the way we roll, baby.

Actually I would even be fine without any migrations and doing them by hand in Montpellier.

#6

Mis à jour par Frédéric Péters il y a presque 9 ans

  • Priorité changé de Normal à Haut
#7

Mis à jour par Frédéric Péters il y a presque 9 ans

  • Assigné à mis à Frédéric Péters
#8

Mis à jour par Frédéric Péters il y a presque 9 ans

J'ai repris le premier patch, réduit à un seul lookup_user() (histoire de ne pas trainer du code servant juste à une phase intermédiaire. (Benjamin, le fixup fait que tu restes marqué auteur du patch, si ça t'ennuie, tu peux le dire); s'il y a création de User lors du lookup_user() j'ai aussi modifié pour qu'il y ait remplissage de la table nameid à ce moment (plutôt qu'attendre l'appel à provision() plus loin, comme il y a un seul type de lookup, ça ne pose pas de soucis).

J'ai ajouté une série de tests (utilisant le testsettings.py qui avait été créé mais pytest, avec une note dans le README).

Comme je le notais ça appellera migration des utilisateurs sur les plateformes qui utiliseraient django-mellon (i.e. montpellier dev/recette et saas dev)

#9

Mis à jour par Benjamin Dauvergne il y a presque 9 ans

Ack.

#10

Mis à jour par Thomas Noël il y a presque 9 ans

Ça m'a l'air ok aussi.

#11

Mis à jour par Serghei Mihai il y a presque 9 ans

Pareil

#12

Mis à jour par Frédéric Péters il y a presque 9 ans

  • Statut changé de Nouveau à Résolu (à déployer)

Ça a été poussé après le ack de Benjamin.

#13

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF