Project

General

Profile

Development #6379

sync-ldap-users do not remove deleted accounts

Added by Benjamin Dauvergne over 4 years ago. Updated 6 months ago.

Status:
Information nécessaire
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
29 Jan 2015
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

If the external_id cannot be resolved in the LDAP, accounts should be removed. It should be customizable with an option like 'sync_delete': True,

The method LDAPBackend.external_id_to_filter can be used for this.

0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch View (2.12 KB) Paul Marillonnet, 12 Feb 2019 12:41 PM

0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch View (2.04 KB) Paul Marillonnet, 12 Feb 2019 12:50 PM

0001-WIP-ldap_backend-process-orphan-accounts-6379.patch View (2.84 KB) Paul Marillonnet, 12 Feb 2019 04:06 PM


Related issues

Related to Publik - Development #26907: Cycle de vie des comptes Nouveau 02 Oct 2018

History

#1 Updated by Benjamin Dauvergne over 4 years ago

  • Target version set to future

#2 Updated by Paul Marillonnet 6 months ago

Up car discuté ce matin sur le salon.

Pas eu le temps de réfléchir au côté CLI (une nouvelle option pour la commande de synchronisation ? une nouvelle commande à part ?)

Mais, dans l'idée, si on se contentait de désactiver les LDAPUsers dont le nom d'utilisateur n'a pas pu être retrouvé dans le LDAP, on est bon ?

#3 Updated by Frédéric Péters 6 months ago

Mais, dans l'idée, si on se contentait de désactiver les LDAPUsers dont le nom d'utilisateur n'a pas pu être retrouvé dans le LDAP, on est bon ?

Les utilisateurs désactivés apparaissent dans le tableau des usagers.

#4 Updated by Paul Marillonnet 6 months ago

Et donc on les supprime, c'est ça (voir le nouveau patch WIP) ?
Est-ce que le comportement le plus souhaitable n'est pas de changer l'affichage des usagers désactivés dans le tableau des usagers ?

#5 Updated by Benjamin Dauvergne 6 months ago

Les utilisateurs supprimés vont disparaître des historiques w.c.s sans #24430, j'aimerai vraiment que tous les aspects cycle de vie des comptes soit reliés et discutés sur #26907 qu'on garde toujours un objectif global et qu'on ne traite chaque petit bout sans voir les conséquences.

Ensuite si c'est un problème temporaires (genre l'annuaire a été branché sur une copie vide, les ACLS sont foirées et ldapsearch ne renvoie plus rien) pim pam poum on vide tout, on perd toutes les affectations de rôle, je serai plutôt pour désactiver le compte, et dès qu'on a un compte disparu du LDAP, déjà désactivé et modifié il y a plus de 3 mois, on supprime.

#6 Updated by Paul Marillonnet 6 months ago

#7 Updated by Paul Marillonnet 6 months ago

Ok d'ac. Est-ce que dans l'idée le code convient ?
(Si oui, j'écris les tests et soumet un patch pour relecture.)

#8 Updated by Paul Marillonnet 6 months ago

Paul Marillonnet a écrit :

(Si oui, j'écris les tests et soumet un patch pour relecture.)

(Et l'ajout de logs sur la désactivation et la suppression).

#9 Updated by Benjamin Dauvergne 6 months ago

_deactivated_on ne va pas persister d'un run sur l'autre, c'est pour cela que j'ai proposé de se servir du champ modified qui existe déjà.

#10 Updated by Benjamin Dauvergne 6 months ago

Mais dans l'idée c'est pas ça du tout, il faut accumuler une liste des external_id_tuples (faut les reconstruire à la volée), extraire celle en base, extraire la première à la deuxième, et les comptes qui reste sont ceux qui sont orphelins; c'est vraiment pas un ticket évident en fait...

#11 Updated by Paul Marillonnet 6 months ago

Ah bein oui zut, j'avais pas pensé à la persistance d'une exécution à l'autre.
Un ticket faussement facile donc (et je ne me l'assigne pas, pour l'instant au moins).

Also available in: Atom PDF