Anomalie #64
fermé
Cohérence entre base Contacts et annuaire LDAP
Ajouté par Grégory MARIGOT - TEICEE il y a presque 14 ans.
Mis à jour il y a plus de 13 ans.
Description
Il y a plusieurs points amenant des incohérences entre les contacts tels que définis dans EpnAdmin et les fiches de l'annuaire LDAP qui en découlent :
- EpnAdmin accepte sans problème les homonymes. Il est possible de créer des contacts différents avec nom+prénom identiques, ils auront bien un id et une référence distincts dans la BdD (et identifiant de connexion unique aussi bien entendu).
Mais au niveau de l'annuaire LDAP, le nom et prénom servent à former le DN, il ne peut donc y en avoir qu'un seul. L'arborescence du LDAP utilisant les groupes, le problème se limite au sein d'un GEPN : pour 2 homonymes, il n'y aura qu'une unique entrée dans le LDAP contenant les données du dernier contact sauvegardé (écrasement). De même en supprimer un dans EpnAdmin supprimera l'entrée commune du LDAP.
- Puisque le DN d'une fiche contact est constitué du nom+prénom, en cas d'édition de ces champs dans EpnAdmin, la fonction de sauvegarde est plus complexe qu'une simple modification : il faut supprimer la fiche pour la recréer avec le nouveau DN. Ceci est géré.
Par contre, le DN contient aussi l'id du groupe (=EPN) après le nom+prénom ! Or la modification de l'EPN de rattachement d'un contact ne déclenche pas la procédure précédente de suppression/création : les attributs de la fiche sont modifiées mais celle-ci reste dans son ancienne arborescence.
Actuellement, la fiche ne serait déplacé qu'en effectuant aussi une modification du nom ou du prénom (avec risque cependant que l'ancienne fiche demeure dans le groupe précédent).
- En dehors de l'écriture dans le LDAP, on peut également se demander si des usagers en doublon sur nom+prénom ne posent pas un soucis dans l'interface d'EpnAdmin avec les sélecteurs de contacts : ceux-ci proposent dynamiquement la liste sous forme nom+prénom, mais alors comment savoir lequel est pris en compte ?
Quelques pistes pour résoudre ces problèmes :
- Utiliser un attribut unique des contacts pour constituer leur DN dans l'annuaire LDAP. Par exemple la référence pourrait remplacer la chaine nom+prénom.
Note : Vérifier que ce changement n'impacte pas l'usage de l'annuaire LDAP par l'OlféoBox.
Exemple :
cn=MARIGOT Grégory,cn=14069,ou=groupes,dc=psepn,dc=ctn
deviendrait
cn=14000398,cn=14069,ou=groupes,dc=psepn,dc=ctn
Ceci permettrait d'autoriser les doublons nom+prénom sans soucis pour le LDAP (si cette possibilité est maintenue par EpnAdmin).
Elle simplifie également le cas de l'édition du nom ou du prénom, qui ne sont plus qu'une sauvegarde classique des attributs de la fiche LDAP sans besoin de supprimer/recréer.
- Malgré la proposition précédente, le changement d'EPN de rattachement d'un contact provoque encore un changement du DN. Ceci pourrait être évité en supprimant l'arborescence par groupes dans l'annuaire.
Néanmoins, on peut souhaiter maintenir ce niveau par simple soucis d'organisation... Rien d'ingérable dans ce cas, il faudra juste prendre soin d'effectuer le traitement spécial de suppression/recréation de la fiche tel qu'actuellement lors des changements de nom ou prénom.
- Faut-il faire un contrôle dans EpnAdmin pour empêcher la création de contacts en doublon sur nom+prénom ? Celà impose une contrainte supplémentaire à la saisie...
En alternative pour ces cas l'ajout des seconds prénoms par exemple (d'autant que l'usage de la virgule fonctionne à présent). Ce controle pourrait raisonnablement limiter son champs de recherche au GEPN, les cas de doublons seraient d'autant plus rares.
Il faut mesurer la nécessité entre cette contrainte éventuelle à l'enregistrement d'un contact, et la problématique possible en cas de doublons ne pouvant être distingués dans les sélecteurs Ajax.
Note : Une évolution liée à celà serait de donner la possibilité de modifier l'identifiant de connexion d'un contact. A priori, la contrainte majeure empêchant celà serait la nécessité de conserver un lien dans le temps entre le contact et les logs de connexion d'Olfeo (sous réserve de ce qui est vraiment utilisé comme id sur l'olfeo... mais normalement celà se limiterait à l'identifiant ou au DN du LDAP).
PS : Le souhait à moyen terme de mettre en place notre propre portail d'authenfication, logs, etc.. en amont de l'OlféoBox nous affranchit d'un certain nombre de contraintes à ce sujet.
- Statut changé de Nouveau à In Progress
- % réalisé changé de 0 à 20
Modifications publiées sur le svn (r292) :
- Le changement de groupe d'un contact fonctionne correctement (en fait la suppression/recréation avait lieu mais la référence au GEPN d'un contact n'était pas remis à jour dans l'objet suite à la modification de son EPN de rattachement).
A présent l'objet 'structureGroup' n'est plus mémorisé dans le profil. L'appel à la méthode getStructureGroup() n'est plus qu'un raccourci pour getStructure()->getStructureGroup(), sans cache de l'objet.
Reste à trancher sur les doublons nom+prénom : s'ils doivent être interdit, alors l'annuaire peut rester tel quel, s'ils sont acceptés il faudrait changer la clef servant pour le DN des contacts.
Proposition :
Ne pas interdire les homonymes, même à l'intérieur d'un groupement.
Faire une association de type Nom_Prénom_id sur le LDAP pour garder visuellement le nom du contact dans Olféo
- Version cible mis à EpnAdmin-CTN 1.1.2
- Statut changé de In Progress à Résolu
- % réalisé changé de 20 à 100
Modifications publiées sur le svn (r295) :
Le RDN de la fiche d'un contact dans le LDAP est désormais formé par le nom, le prénom + l'identifiant de connexion qui assure l'unicité totale dans l'annuaire, par ex: cn=MARIGOT Grégory (gmarigot)
Ainsi les doublons par homonymie restent permis et ne posent plus de problème pour être stockés correctement dans l'annuaire.
- Statut changé de Résolu à Fermé
Formats disponibles : Atom
PDF