Anomalie #69
ferméRévision du support LDAP pour les fiches contacts
100%
Description
Chaque sauvegarde d'un contact provoque l'enregistrement dans l'annuaire LDAP sous la forme d'une suppression (le login servant de clef) puis recréation, alors que souvent une modification serait plus appropriée.
Parfois la répercution vers le LDAP est même inutile. Par exemple la connexion sur EpnAdmin change le champs last_login qui n'intéresse pas l'annuaire (suppression/recréation inutile). Ou encore l'enregistrement d'un nouveau contact qui fait un 1er "save" en BdD pour récupérer le nouvel id, l'enregistrement Ldap pourrait se faire uniquement sur le "save" final.
La branche des fiches (idem pour les groupes) est indiquée en dur dans les classes CtnUserLdap et CtnGroupLdap. On peut préférer avoir cette donnée regroupée dans la configuration de l'annuaire (app.yml).
La gestion de l'uidNumber des fiches Ldap en génère un nouveau à chaque création de manière incrémentale. Si celà assure un uidNumber unique, il change à chaque recréation donc actuellement à chaque modif. Si ce n'est pas génant actuellement, ce champs n'ayant pas d'utilité, ce n'est pas logique pour autant et nous prive d'une éventuelle utilisation de cet uid.
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Modifications publiées sur le svn (r292) :
- Suppression de la classe EPNadminLdap au profit d'un usage direct de la classe Ldap. Pour celà cette dernière a évolué en disposant d'un constructeur qui va récupérer les informations nécessaires dans le fichier de configuration app.yml.
- La configuration d'un annuaire Ldap contient désormais son BaseDN. Cette données est récupéré à la construction d'un objet Ldap, il n'est donc plus nécessaire d'avoir ce chemin en dur dans les classes CtnUserLdap et CtnGroupLdap.
- Amélioration de la classe Ldap par l'ajout de quelques méthodes et paramètres optionnels : prise en compte du BaseDN, récupération du DN ou du RDN, méthodes copy() et rename() en cas de changement du DN...
- La sauvegarde vers le LDAP gère la modification des fiches (auparavant elles étaient systématiquement supprimées pour être recréées). Ceci évite des requêtes inutiles et permet de mieux gérer les attributs ne devant pas être modifiés (password, uidNumber).
- Le champs uidNumber des contacts dans l'annuaire n'est plus défini de manière incrémental : il est déterminé à partir de l'id du user dans la BdD (+ 1000). Cette méthode permet facilement d'avoir un uid unique (sur l'ensemble du Ldap et pas uniquement au groupe comme auparavant). De plus le lien peut être établi entre EpnAdmin et l'annuaire (possibilité d'utiliser ce champs comme clé au lieu du login par exemple).
- Désactivation de la synchro LDAP lors de la sauvegarde d'un contact pour certaines opérations (ex: enregistrement du last_login qui auparavant provoqué suppression/recréation du contact inutilement), grâce à un flag activable par $user->setSyncLdap()
En bref : le support Ldap a été révisé pour mieux gérer l'annuaire, la configuration est mieux centralisée, le nombre de requêtes vers l'annuaire a été réduit au strict nécessaire.
PS: Une modification a aussi été retirée lors de l'enregistrement en BdD d'un user avec son profil : le user été sauvé 2 fois. Mais l'enregistrement avant son profil ne semble pas nécessaire.
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
Modifications publiées sur le svn (r299) :
A noter qu'un changement a été effectué sur la valeur du champs UidNumber.
L'utilisation de la référence des contacts a été préférée à l'Id des fiches dans la BDD. Cette référence est également de type numérique et unique, elle peut donc faire l'affaire tout en étant plus pertinente qu'un id interne à la base sql sans intérêt particulier.
Ce choix sera actif avec la version cible 1.1.3
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
- Statut changé de Résolu à Fermé