Open EC2311 opened 6 years ago
oui tout a fait. j'exposais un peu cette possibilité "_En attendant y aurait-il une solution de pouvoir saisir une zone et d'utiliser cette zone ((ex ##answer_285##) pour alimenter le filtre de la selection (ex dans filtre : (& (cn=##answer_285##R) (&(objectClass=Group)))_"
Ce ticket a plus de 2 ans, et pas mal de mesages. On est d'accord que dans votre formulaire, la dropdown à ce jour affiche "aucune résultat" ?
Je me demande si vous n'avez pas tout bêtement une exception. Il y a un bloc try / catch. Peut être qu'on tourne en boucle sur les résultats jusqu'à une exception. Dans ce cas, la méthode ne retourne rien.
Essayez le patch suivant, testez votre question et voyez si il y a quelque chose dans php-errors.log
diff --git a/inc/field/ldapselectfield.class.php b/inc/field/ldapselectfield.class.php
index 425de1a6..fea8c492 100644
--- a/inc/field/ldapselectfield.class.php
+++ b/inc/field/ldapselectfield.class.php
@@ -39,6 +39,7 @@ use Exception;
use Html;
use Session;
use RuleRightParameter;
+use Toolbox;
class LdapselectField extends SelectField
{
@@ -199,6 +200,7 @@ class LdapselectField extends SelectField
asort($tab_values);
return $tab_values;
} catch (Exception $e) {
+ Toolbox::logDebug("formcreator: " . $e->getMessage() , Toolbox::backtrace(''));
return [];
}
la dropdown affiche depuis toujours des resultats, mais de maniere incomplete : il me manque pas mal de resultats.
Par contre je ne trouve pas l'endroit des insertions : use HTML n'apparait pas dans mon source. Je suis en 2.10.4
Bon j'ai trouvé un truc :) en fait quand je fais un print_r array_shift($entries); print_r ($entries);
je retrouve bien dans l'ensemble des variables les utilisateurs qui devraient apparaitre alors dans le dropdown :) donc le probleme ne vient pas de la recherche ldap, mais du remplissage dropdown.
le tableau tab_values est systématiquement ecrasé ! pour ne contenir (en return value) que la derniere occurence !
je pense que le souci viendrait de $id... mais la ne connaissant pas le php...
dans l'affichage du contenu issu de print_r $tabvalue, on passe de [999] à [5] (par exemple, fonction des attr) etc...
voila le bug :) (enfin je pense)
j'ai reussi à faire fonctionner en tenant compte du nombre de fois que l'on passe dans la boucle et initialement mis à 0 -> $ress : compteur de boucle... multiplié par le nombre de poste (taille de la page du ldap, ici à 1000)
lorsque je debug (print_r tab_values) j'obtiens bien TOUS les postes. :)
Par contre, je trouve que le temps de reaction (lorsque l'on tape une lettre dans le dropdown) est assez lent...
Bonjour
Ce que vous avez trouvé me semble juste. la variable $id est un numéro commençant à 0 ou 1 pour chaque nouvelle page, c'est cela ?
Je viens de faire uen vérification : la valeur $id n'est pas utilisée pour la les cas d'utilisation suivant l'affichage du formulaire. Je valide donc la solution, mais je la ferais de manière plus simple. La variable $ress n'existe pas dans le code original, donc c'est sûrement une variable que vous avez créée, et qui contient le numéro de la page courante ?
Du coup je verrais cette PR en solution #2144
EDIT : Niveau performance de la dropdown côté navigateur, c'était ce que je craignais. Il faut passer à une dropdown à chargement dynamique.
En effet, j'ai créé moi meme la variable $ress afin de tester et resoudre le probleme. c'est une variable incrementée dans la bouche (do/while) Je pense qu'il faut tenir compte de la 'taille page ldap' je l'ai positionnée à 1000 , car c'est cette valeur qui se trouve dans la definition du ldap.
Pour information, j'ai fait la modif dans différentes versions du plugin avec succés.
Bonjour
Le patch #2144 devrait être insensible à la taille des pages. Pouvez vous l'essayer ?
Bonjour, J'ai fait un test, mais ma foi je ne vois pas trop de différence. Je pense que c'est du surtout à la taille du ldap dont le temps de chargement est assez long avant d'etre affiché dans la fenetre (je fais test en previsualiation formulaire)
Néanmoins j'ai noté quelque chose surprenant : (et ce sans votre patch) Lorsque je saisis els lettres de 'preselection' le resultat n'est pas le meme.
En 2.8.5,si je saisis BANC j'obtiens bien des personnes 'contenant' BANC. en 2.10.4, meme selection (soit BANC), j'obtiens des personnes comportant BA soit beaucoup plus : on ne voit pas la 'selection' soulignée dans le nom...
Bonjour
Si ma version fonctionne bien, je peux merger. L'amélioration pour le chargement lazy requiert plus de travail, et un sponsor serait le bienvenu.
Bonjour
La future versoin 2.13.0 implémente désormais un lazy loading des éléments provenant du LDAP, permettant également de faire une recherche en saisissant une partie de l'item souhaité
super :)
Bonjour Je reviens un peu sur ce "bug" et sur le PR https://github.com/pluginsGLPI/formcreator/pull/2144
en 2.13.7 la liste semble fonctionner.
Bonjour Il ne devrait plus y avoir de problème avec ces type de champ, sauf (selon quelques remontées anciennes) si vous utilisez une version datée de PHP (7.4 de mémoire).
Bonjour
je suis avec GLPI 9.2.3 et formCreator 2.6.4
j'arrive à importer des utilisateurs et des groupes AD. OK
Lorsque je cree un formulaire avec un composant lié LDAP, le resultat est toujours 'Aucun resultat' : je prends la meme structure de filtre que celui declaré dans le LDAP GLPI.
Pourquoi ? Quelle serait le type de filtre à renseigner ? attribut (AD/LDAP?)
D'avance merci