Development #52670
ldap: réactiver les comptes LDAP s'ils réapparaissent
0%
Description
Un compte LDAP qui serait sorti du filtre et qui y revient va actuellement rester désactivé.
Fichiers
Révisions associées
Historique
Mis à jour par Benjamin Renard il y a environ 3 ans
- Fichier 0002-LDAPBackend-reactive-user-on-login-synchronization-i.patch 0002-LDAPBackend-reactive-user-on-login-synchronization-i.patch ajouté
Cf. #52917, je propose ici un patch réactivant les utilisateurs suite à connexion réussie et lors de la synchronisation.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Statut changé de Nouveau à En cours
Dans mon idée il faudrait noter que le compte inactivé l'a été pour absence lors d'une synchro et pas par un administrateur; parce que là ça veut dire qu'on ne peut plus bloquer un compte LDAP depuis l'administration. Ça suppose un champ supplémentaire deactivation_reason = models.TextField(...) où on pourrait mettre 'sync-ldap' et réagir en conséquence.
J'ai un autre ticket (#52672) pour supprimer les comptes désactivés au bout d'un certain temps (histoire que les soucis de synchro ne provoquent pas des catastrophes).
Mis à jour par Serghei Mihai il y a environ 3 ans
Benjamin Dauvergne a écrit :
Dans mon idée il faudrait noter que le compte inactivé l'a été pour absence lors d'une synchro et pas par un administrateur; parce que là ça veut dire qu'on ne peut plus bloquer un compte LDAP depuis l'administration. Ça suppose un champ supplémentaire
deactivation_reason = models.TextField(...)où on pourrait mettre 'sync-ldap' et réagir en conséquence.
Je pensais plutôt à un deactivation_reason = models.CharField(choices=...) et dans choices avoir un identifiant technique de la raison de desactivation, exploitable dans le code, et un libellé traductible à afficher en backoffice.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Les choices c'est surtout utile pour avoir une interface en front (faire des ModelForm), ça n'a aucun effet sur le modèle ou la base (on pourra toujours écrire user.deactivation_reason = 'coin') mais oui avoir des codes techniques comme ldap ou backoffice était bien ce à quoi je pensais, il faut par ailleurs l'ajouter aussi au journal qui note la désactivation.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
- Fichier 0001-LDAPBackend-reactive-user-on-login-synchronization-i.patch 0001-LDAPBackend-reactive-user-on-login-synchronization-i.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
- Fichier 0001-LDAPBackend-reactive-user-on-login-synchronization-i.patch 0001-LDAPBackend-reactive-user-on-login-synchronization-i.patch ajouté
tests corrigés et rebasé sur main.
Mis à jour par Serghei Mihai il y a presque 3 ans
- Statut changé de Solution proposée à Solution validée
J'ai corrigé un dernier test et mis à jour la branche.git pull et go.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 231f1e7b7c0124aedf1e1ab7462463c79aa1390f
Author: Benjamin Renard <brenard@easter-eggs.com>
Date: Fri Apr 9 16:44:49 2021 +0200
LDAPBackend: reactive user on login/synchronization if inactive (#52670)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
LDAPBackend: reactive user on login/synchronization if inactive (#52670)