You are not logged in.
Pages: 1
Topic closed
Bonjour,
Quelques pistes / besoins d'amélioration de la gestion de l'import des utilisateurs depuis un annuaire LDAP
1/ association annuaire / entité
Actuellement on a la possibilité de stocker le DN sur la fiche de l'entitié, il me semblerait intéressant d'avoir aussi la référence de l'annuaire, en effet dans le cas ou on a plusieurs LDAP de même structure, on risque d'avoir des doublons.
Aujourd'hui cela permet d'associer l'entité depuis son DN
Cette évolution permettrait de rechercher les utilisateurs depuis une entiité
2/ simplification / délégation de l'import des utilisateurs
Dans le cas ou un "administrateur délégué" peut faire l'import des utilisateurs, il serait préférable de mieux filtrer la recherche (en particulier pour un annuaire global très volumineux, pour ne pas atteindre la limite de recherche, souvent 500) et surtout ne pas lui proposer des utilisateurs qui ne seront en final pas dans son entité.
- faire la recherche dans l'annuaire et le DN de l'entité courante si il est définit
- proposer des critères de recherche explicites correspondant aux champs mappés plutôt que la zone "critères ldap" (trop technique) : l'admin voit le nom des champs (Nom, Prénom, Téléphone, ..) et on génère la requête à partir des infos de configuration
3/ ajout depuis la fiche de création d'un ticket
Si on veut éviter de charger tous les utilisateurs, on pourrait utiliser un bouton "+" à côté de la dropdown "demandeur" pour obtenir un popup de recherche et d'ajout de 1 utilisateur (même formulaire que pour 2)
Peut-être qu'il faut aussi une option de configuration / habilitation pour cette fonctionalité afin de ne pas devoir donner les droits d'écriture sur tous les utilisateurs, mais uniquement de chargement.
4/ recherche Ajax d'un utilisateur
Ajouter quelque critères de recherche d'un utilisateur : nom, prénom, téléphone, email
En particulier, beaucoup de technicien "hotline" ont la présentation du numéro, cela éviterait de demander son nom au "client".
Est-ce que cela vous semble cohérent ?
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Voir : http://www.glpi-project.org/forum/viewt … p?id=14735
Donc pour le 2 : prévoir l'option "entity" au script mass_ldap_sync (donc, au choix annuaire ou entité).
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Quelques pistes / besoins d'amélioration de la gestion de l'import des utilisateurs depuis un annuaire LDAP
1/ association annuaire / entité
Actuellement on a la possibilité de stocker le DN sur la fiche de l'entitié, il me semblerait intéressant d'avoir aussi la référence de l'annuaire, en effet dans le cas ou on a plusieurs LDAP de même structure, on risque d'avoir des doublons.
Aujourd'hui cela permet d'associer l'entité depuis son DN
Cette évolution permettrait de rechercher les utilisateurs depuis une entiité
oui effectivement, ça vaudrait la peine de traiter ça avec ce ticket :
https://dev.indepnet.net/glpi/ticket/1186
2/ simplification / délégation de l'import des utilisateurs
Dans le cas ou un "administrateur délégué" peut faire l'import des utilisateurs, il serait préférable de mieux filtrer la recherche (en particulier pour un annuaire global très volumineux, pour ne pas atteindre la limite de recherche, souvent 500) et surtout ne pas lui proposer des utilisateurs qui ne seront en final pas dans son entité.
ça veut dire passer le moteur de règles complet pour chaque utilisateur au moment de la présentation des users à importer si on est sur l'entité racine en récursif...
- faire la recherche dans l'annuaire et le DN de l'entité courante si il est définit
oui ça c'est une très bonne idée
- proposer des critères de recherche explicites correspondant aux champs mappés plutôt que la zone "critères ldap" (trop technique) : l'admin voit le nom des champs (Nom, Prénom, Téléphone, ..) et on génère la requête à partir des infos de configuration
oui on peut le faire et ça a du sens. C'est vrai que ça pourrait bien simplifier la vie.
3/ ajout depuis la fiche de création d'un ticket
Si on veut éviter de charger tous les utilisateurs, on pourrait utiliser un bouton "+" à côté de la dropdown "demandeur" pour obtenir un popup de recherche et d'ajout de 1 utilisateur (même formulaire que pour 2)
Peut-être qu'il faut aussi une option de configuration / habilitation pour cette fonctionalité afin de ne pas devoir donner les droits d'écriture sur tous les utilisateurs, mais uniquement de chargement.
tu veux dire reproduire le comportement de "ajouter depuis une source externe" ?
4/ recherche Ajax d'un utilisateur
Ajouter quelque critères de recherche d'un utilisateur : nom, prénom, téléphone, email
En particulier, beaucoup de technicien "hotline" ont la présentation du numéro, cela éviterait de demander son nom au "client".
oui, surtout le numéro de téléphone !
Offline
ça veut dire passer le moteur de règles complet pour chaque utilisateur au moment de la présentation des users à importer si on est sur l'entité racine en récursif...
Pas forcément.
Si je donne ce droit à l'utilisateur, c'est que le critère "DN" est suffisant, donc il vera que les utilisateurs concernant son entité.
tu veux dire reproduire le comportement de "ajouter depuis une source externe" ?
Oui, enfin la version simplifée décrit au point 2.
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
je déplace les réflexions sur l'espace de dev.
https://dev.indepnet.net/glpi/wiki/ImproveLdapImport
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Pages: 1
Topic closed