Anomalie #64

Cohérence entre base Contacts et annuaire LDAP

Added by Grégory MARIGOT - TEICEE about 12 years ago. Updated over 11 years ago.

Status:Fermé Start date:06/29/2010
Priority:Normal Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:EpnAdmin-CTN 1.1.2
Version ProxyEPN:1.0

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 ?

Related issues

related to Anomalie #69: Révision du support LDAP pour les fiches contacts Fermé 07/12/2010
related to Evolution #72: Regénération de l'annuaire LDAP à partir de la BdD EpnAdmin Fermé 07/15/2010

Associated revisions

Revision 292
Added by Grégory MARIGOT - TEICEE almost 12 years ago

FIX #64: Révision du support LDAP et de l'enregistrement des fiches contacts

Revision 295
Added by Grégory MARIGOT - TEICEE almost 12 years ago

FIX #64: Le DN des contacts LDAP contient le login en plus du nom+prénom pour gérer les homonymes.
NEW #72: Une action user/ldapRegen permet à l'admin de regénérer les groupes et fiches de l'annuaire Ldap.
FIX #69: Quelques corrections et controles supplémentaire sur les classes Ldap révisées.
CHANGE #70: Seul l'admin peut anonymiser les contacts, pour les autres la page invite à le contacter.

History

Updated by Grégory MARIGOT - TEICEE about 12 years ago

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.

Updated by Grégory MARIGOT - TEICEE almost 12 years ago

  • Status changed from Nouveau to In Progress
  • % Done changed from 0 to 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.

Updated by Jérôme LAMACHE almost 12 years ago

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

Updated by Grégory MARIGOT - TEICEE almost 12 years ago

  • Target version set to EpnAdmin-CTN 1.1.2

Updated by Grégory MARIGOT - TEICEE almost 12 years ago

  • Status changed from In Progress to Résolu
  • % Done changed from 20 to 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.

Updated by Grégory MARIGOT - TEICEE over 11 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF