Projet

Général

Profil

Development #46650

Ambiguité à la déclaration de la politique de réinitialisation de mot de passe lors de la création d'une OU

Ajouté par Paul Marillonnet il y a plus de 3 ans. Mis à jour il y a presque 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
15 septembre 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Lorsqu'on crée une OU on doit déterminer si les usagers de cette OU peuvent réinitialiser eux-mêmes leur mot de passe, en choisissant parmi “Oui”, “Non” mais aussi “Inconnu”…
C'est parce que le champ derrière qui gère ça est un NullBooleanField (mais ça ne semble pas justifié après une relecture de cette partie du code).


Fichiers

Révisions associées

Révision dc266701 (diff)
Ajouté par Paul Marillonnet il y a presque 3 ans

utils: reshuffle user flag retrieval precedence (#46650)

Révision 2928bbf7 (diff)
Ajouté par Paul Marillonnet il y a presque 3 ans

a2_rbac: fix inconsistencies in OUs' user password reset option (#46650)

Historique

#1

Mis à jour par Paul Marillonnet il y a plus de 3 ans

Et on me dit qu'il y a de l'existant avec ‘Inconnu’ positionné comme valeur pour certaines OUs. Il faut aussi la migration qui passe cette valeur ‘Inconnu’ vers la bonne valeur booléenne par défaut.

#2

Mis à jour par Paul Marillonnet il y a plus de 3 ans

(Et en fait le moteur de migration de Django opère tout seul la conversion de null à la valeur par défaut (en l’occurrence True) lors de l'application de la migration.)

#3

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

Le but du nul c'était d'utiliser la valeur par défaut du système, je pense, mais je n'ai pas regardé si le code fait bien ça.

#4

Mis à jour par Paul Marillonnet il y a plus de 3 ans

Benjamin Dauvergne a écrit :

Le but du nul c'était d'utiliser la valeur par défaut du système, je pense, mais je n'ai pas regardé si le code fait bien ça.

git-grep ne renvoie rien, je ne vois ça nulle part.

#5

Mis à jour par Paul Marillonnet il y a plus de 3 ans

  • Statut changé de Solution proposée à Information nécessaire

Benjamin Dauvergne a écrit :

Le but du nul c'était d'utiliser la valeur par défaut du système, je pense, mais je n'ai pas regardé si le code fait bien ça.

Et donc je n’ai pas deviné ça à la lecture du code, qui n’en présente pas trace. Est-ce qu’on laisse comme ça ou bien on définit un setting global que la configuration par OU pourrait venir surcharger ?

#6

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

C'est dans authentic2.utils.get_user_flag, la valeur None est ignorée. Par contre le code est con la valeur des settings surcharge tout :/ Faudrait inverser ce code mais je ne vois pas de raison d'enlever le support du NULL, à la rigueur changer "Inconnu" par valeur par défaut, et afficher la valeur prise en page de détail.

#7

Mis à jour par Paul Marillonnet il y a plus de 3 ans

  • Statut changé de Information nécessaire à En cours
  • Assigné à mis à Paul Marillonnet

Oui ok ce sera mieux ainsi.

#10

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

  • Statut changé de Solution proposée à Solution validée
#11

Mis à jour par Paul Marillonnet il y a presque 3 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 2928bbf7040d0159e1f799e30d48aac9745a3508
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Tue Oct 27 12:18:37 2020 +0100

    a2_rbac: fix inconsistencies in OUs' user password reset option (#46650)

commit dc26670153a005d8b0fc277aba2c627c355164f1
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Tue Jun 22 15:33:17 2021 +0200

    utils: reshuffle user flag retrieval precedence (#46650)
#12

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

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF