Création User et recherche LDAP

Bonjour,

Sur un objet, j’ai besoin d’attacher un objet User.

Si à la recherche je ne le trouve pas, je peux le créer via le bouton Create du formulaire de recherche.

Est-il faisable de déclencher, si on commence à remplir les champs en vue d’une création, une connexion LDAP à l’annuaire d’entreprise, qui pré-remplirait les champs login, nom et prenom ? Ou est-ce trop spécifique.
Y a-t-il des bonnes pratiques à ce sujet, peut-être en passant par un autre écran ?

Merci d’avance !
Emmanuelle

En premier lieu, il faut créer un objet qui hérite de User pour permettre de faire de choses spécifique sans modifier le comportement du User Simplicité car déjà “scripté”. Et de mapper cet objet dans vos FK pour que l’écran de création soit le bon.

Ensuite votre besoin est d’avoir un “lookup” sur le login + le nom / prenom, plusieurs pistes :

  • Soit il faut créer un objet service table=“service-ldap” qui implémente la recherche dans le LDAP
    puis créer des Datamap sur vos 3 champs et cet objet. Ca affichera un bouton lookup à côté du premier champ mappé. Les datamap marchent aussi en completion si le champ à la propriété.
    https://docs.simplicite.io/documentation/05-remote/ldap.md

  • Soit créer une action spécifique sur votre formulaire pour invoquer une action qui récupère les champs, appelle le LDAP et remplit les champs avec l’utilisateur trouvé (ou afficher un liste de choix…)

  • Soit par completion simple en surchargeant le hook fieldCompletion
    public List<String> fieldCompletion(String input, String query, String context)
    qui par défaut va chercher dans la base de donnée, mais peut aller chercher ailleurs et retourner un liste de résultats que le front pourra servir dans les champs en splittant la ligne sélectionnée (pas de bouton lookup affiché donc moins compréhensible, à réserver pour compléter une ville de code postal par exemple)

1 Like

Bonjour,

J’essaie d’implémenter la première option mais je ne comprends pas cette partie :

" A good practice is to use the uid attribute for the custom row ID field of your object."

Comment paramétrer un champ row id custom alors qu’il existe déjà par défaut ?

Merci !

exemple:

avec :

Les noms physiques des autres attributs sont bien aussi les noms des attributs LDAP

Merci, donc si je comprends bien, par “custom Row ID” on entend plutôt clé primaire de l’objet service-ldap ? Pas le champ row_id

“Custom row ID” signifie un “row ID (clé primaire) spécifique”
Cet attribut prendra la place et le rôle de l’attribut standard row_id

1 Like

Pour finir avec mon exemple j’ai ajouté sur mon objet LDAP un attribut non persistant qui concatène certains attributs LDAP:

Et j’ai mis un datamap sur cet attribut calculé dans un autre objet:

Résultat sur cet objet j’ai un attribut “lookup” comme ça:

Un grand merci pour vos réponses rapides et les exemples, je galérais un peu à configurer le mapping :-)

J’ai encore deux questions :

  • est-il possible d’avoir l’auto complétion pour les champs LDAP ? Sur les champs de l’objet service-ldap j’ai activé l’option auto compétion et champ indexé mais ça n’a pas l’air de fonctionner

  • j’ai mappé mes 3 champs login, nom et prénom comme conseillé mais j’ai 3 loupes et pas une ; quand je choisis une valeur les autres ne sont pas remplies automatiquement. Est-ce que je dois faire un populate par code ? Ou j’ai mal paramétré quelque chose ?

Merci !

C’est pour éviter les 3 lookups que j’ai configuré un attribut calculé qui concatène les attributs que je veux récupérer. Je ne suis pas non plus un expert des data mappings, si ma mémoire est bonne on regroupe des data mappings en leur donnant le même nom

Je laisse @Francois confirmer mais la complétion ne fonctionnera pas nativement dans un contexte comme celui là

1 Like

Il faut configurer 3 datamaps de même nom pour grouper les champs au sein d’un même lookup.
Un évolution récente utilise le datamp pour chercher par complétion, donc c’est à l’objet lié de bien prendre en compte les filtres.

Attention aux champs que vous mettez en in/out (in = filtre à appliquer / out = champ récupéré).
Car derrière il faut que le service LDAP applique bien ces filtres et je ce sais pas si c’est le cas, sur login/nom/prénom de type “like”.

Il suffit d’afficher votre objet LDAP depuis le menu et d’essayer de filtrer les champs, pour voir si cela fonctionne.

1 Like

Un objet de type “service-ldap” applique bien les filtres sur les attributs LDAP

1 Like

Merci j’ai regroupé les datamap et je n’ai plus qu’une loupe pour les 3 champs.
Par contre l’autocomplétion ne fonctionne pas sur mon objet “service-ldap”, quand je commence à écrire dans une des zones de recherche rien n’est proposé. Pourtant j’ai bien indexé et activé l’autocomplétion.
Est-ce que la fonctionnalité est disponible en 4.0 ?

La complétion fonctionne sur l’index interne de Simplicité, or les objets services ne sont pas indexés. Je ne sais pas quel volume d’information est dans le LDAP mais tout remonter pour indexation dans Simplicité n’est à priori sans doute pas raisonnable (et peut être techniquement pas possible)

@françois y a il une astuce pour implémenter une logique de complétion custom coté UI ? Ou d’indexation custom coté serveur ?

1 Like

Non, une complétion de champ “simple” est un like sur la colonne en base (on cherche dans les valeurs déjà connues). Il n’y pas d’indexation particulière. (l’indexation d’objet sert à ramener une completion pour les objets liés via FK, ou un objet en pillbox).

Une évolution récente utilise le Datamap comme objet de complétion pour un champ simple mappé en “in” entrant (au lieu de sa colonne en base) = donc c’est un search sur l’objet mappé. Ca a bien été backporté en V4 pour un gros projet qui ne nous a pas remonté de problème de fonctionnement.

Il faut ajouter des traces dans votre objet ldap (l’instance pour la recherche commence par datamap_ajax_) pour voir si un search (au preSearch et postSearch) est appelé et avec quel filtre.

  • Si le datamap est “in” entrant uniquement = c’est un filtre d’égalité stricte
  • Si le datamap est “in/out” = c’est un filtre xxx%

Vous pouvez modifier le filtre au preSearch pour l’adapter à la recherche LDAP (ajouter un % devant par exemple).

  • Faire une recherche sur le prénom n’a pas d’intérêt à mon avis, il faut laisser ce datamap uniquement sortant = “out”
  • Il n’y a qu’un seul filtre utilisé par la completion = celui du champ dans lequel on est, on ne peut pas mixer le login et le nom par exemple.
  • pour une recherche complete il faut utiliser le bouton lookup / liste avec tous les filtres
1 Like

NB: Attention le mécanisme de construction du filtre d’un objet service LDAP est un peu subtil car c’est “traduit” en syntaxe LDAP, les cas simples genre “dupon*” ou “*pont” marchent, mais des choses plus complexes pas forcément.