Chez moi (et sur d’autres sites de démo) et sur la même V12.0.3, ce n’est pas le cas, aucun produit n’est sélectionné si je ne clique pas dans la liste :
Bonjour,
C’est bizarre car avec ma douchette tout fonctionne correctement après l’avoir paramétré avec « entrée » après le scannage.
Avez-vous bien vérifié que le soucis ne vient pas de la douchette? Quel est le modèle?
J’ai essayé deux douchettes, l’une « Symbol » ancienne qui n’est pas du tout paramétrable et qui envoie le CR/LF à tous les coups, L’autre Welquic, plus récente qui peut envoyer ou non le CR/LF au choix.
Donc il me parait peu probable que ce soit un problème de douchette, d’autant plus que je vois deux sites Dolibarr qui réagissent différemment.
Pour moi c’est une histoire de focus sur le 1er résultat.
Sur mon Dolibarr, j’ai tenté de désactiver javascript dans la configuration d’affichage et bien le comportement change mais les codes barre ne sont plus reconnus, par contre un produit est sélectionné systématiquement avec les premiers caractères tapés, en faisant entrée le produit est confirmé, et un deuxième entrée ajoute le produit et sa quantité. C’est très proche du comportement attendu sauf que le javascript est tout de même bien utile et surtout la sélection sur code barre !
Donc je penche sur un problème de javascript dans le coin…
Sans CR/LF ni rien d’autre tu peux avoir une selection auto si il y a une seule correspondance avec ce que tu as saisi.
Dans /htdocs/core/class/htmlform.class.php la fonction select_produit $out .= ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.'/product/ajax/products.php', $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 0, $ajaxoptions);
à modifier comme suit: $out .= ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.'/product/ajax/products.php', $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);
Merci pour la suggestion, je vais essayer ça, et effectivement je suis certain que cela va fonctionner.
Et c’est bien meilleur que de sélectionner le 1er de la liste…
La modification ne serait-elle pas à intégrer (et généraliser) dans le core sachant qu’elle me semble améliorer l’ergonomie et la productivité ?
Cela pourrait aussi être paramétrable avec une donnée accessible à l’administration…
Merci pour l’essai, car je n’ai pas eu le temps aujourd’hui.
Mais ce n’est pas une très bonne nouvelle car certaines douchettes ne sont pas paramétrables et d’ailleurs le fait qu’elles envoient le CR/LF est un gain de temps en soi puis que la donnée dans le champ forcément reconnue (car unique) est aussitôt validée, ce qui évite une frappe entrée au clavier…
Je viens de faire l’essai
en fait en 12.0.3 dans le même fichier, je n’ai pas le code que tu indiques donc j’ai cherché :
$conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 0, $ajaxoptions);
J’ai trouvé deux lignes portant ce code :
La ligne 2045 où j’ai remplacé 0 par 1
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.‹ /product/ajax/products.php ›, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);
La ligne 2797 où j’ai fait de même :
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.‹ /product/ajax/products.php ›, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);
Le produit est bien capté sur la zone et au CR/LF (touche entrée) le curseur passe dans la zone de texte en dessous. Il suffit de taper 2 fois sur la touche TAB pour se retrouver à la saisie de la quantité, et on valide le tout par un nouvel appui sur la touche entrée.
Je ne trouve pas ça si mal mais j’ai fait la simulation à la main sans douchette que je n’ai pas sous la main ce soir. Sur le site de démo que j’ai cité, ils ont fait le choix de présélectionner (en bleu) la 1ère ligne systématiquement et le CR/LF (ou touche entrée) la valide, ce qui est efficace si la 1ère ligne convient et aussi pour une douchette car il n’y a qu’une seule ligne ou rien du tout. L’avantage étant que le curseur ne passe pas dans la zone de texte.
Mais le comportement est peut-être différent aussi car ils affichent tous les produits sans taper le moindre caractères, or j’ai plus de 10000 produits et si je fais ça la liste met trop de temps à s’afficher donc je contraints à la frappe préalable d’au moins 2 caractères avant l’affichage de la liste.
Je pense avoir compris ces changements de comportement entre les sites à la validation de la saisie, ils sont bien liés au paramètre du module produits définissant le nombre de caractères à frapper avant que la liste n’apparaisse. Il faut que j’approfondisse ces cas pour optimiser la saisie à la douchette…
Le fonctionnement est différent selon le réglage dans le module produits de la recherche. Si tu désactive la recherche ajax, la selection affiche les produits et le premier résultat est sélectionné et là, la douchette marche avec le cr/lf. Si tu as 10 000 produits, il faut passer en recherche ajax (nombre de caractères déclenchant la recherche etc)
Bonjour,
ce matin j’ai approfondi à tête reposée l’impact des réglages du module produits sur la recherche produit de la commande client.
J’ai restitué le code à son état d’origine :(PRODUIT_USE_SEARCH_TO_SELECT, 0,)
J’ai utilisé le navigateur Firefox [83.0 (64 bits)].
Dans la génération automatique de codes à barres, j’ai paramétré le masque EAN13 par défaut à 020{0000000000} (sur 13 caractères car mes codes ont 13 caractères.
Le facteur essentiel de mes problèmes est tout de même le nombre de produits 10890 exactement…
Dans la configuration du module produits,
si le paramètre : Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits = NON
et si le paramètre : Nombre maximum de produits dans les listes déroulantes = 0
Dans commerce, saisie d’une commande client, lorsqu’on clique dans la zone Produits/Services prédéfinis en vente :
la liste en ajax s’affiche en 5 à 6 secondes, ce qui est déjà rédhibitoire,
la saisie, alors, d’un code à barres par douchette avec CR/LF déclenche bien la sélection du bon produit mais au bout de 11 secondes d’attente !!! Ce qui est absolument insupportable.
Mais fonctionnellement c’est impeccable.
Ensuite tout changement au paramétrage du module produits provoque le dysfonctionnement complet de la saisie du code à barres par douchette.
Par exemple si le paramètre :
Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits = OUI (quelque soit le nb de caractères choisi de 1 à 3),
Si on laisse le paramètre : Nombre maximum de produits dans les listes déroulantes à 0
Lorsqu’on tente de saisir à la douchette (avec CR/LF) un code à barres (le même), jamais rien n’est sélectionné. Il semblerait que ça va trop vite pour le système (le CR/LF valide avant que la sélection ait opérée)
Si on fait la même saisie à la main (ou par copier/collé), donc moins vite, la sélection finie par se faire rapidement mais, sans le patch, la touche entrée est inopérante, il faut descendre sur l’unique produit avec la flèche vers le bas du clavier ou opérer la sélection à la souris.
Si j’applique le patch :(PRODUIT_USE_SEARCH_TO_SELECT, 1,) aux 2 lignes citées ci-dessus, le code à barres saisi à la main (ou copié/collé) est rapidement remplacé par la référence produit sur la ligne même de saisie et la touche entrée est efficace et fait passer au champ suivant. Mais rien à faire pour qu’une douchette (avec CR/LF, je n’ai que ça sous la main aujourd’hui), ait la même efficacité, le code à barres disparait après le CR/LF et c’est tout.
Si on change le paramètre : Nombre maximum de produits dans les listes déroulantes à autre chose que 0 (500 par exemple) le code barre peut ne pas être trouvé et est rejeté (aucun enregistrement trouvé)…
Si, avec le patch, je reviens à ma config d’origine, la 1ère attente est la même 4 à 5 secondes mais à la saisie par la douchette, le produit est sélectionné plus rapidement, environ 4s ce qui est bien mieux que 11s.
J’ai fait des essais sur Chrome et Edge, dans le cas de l’affichage de tous les produits par ajax. Là c’est carrément pire aucun des deux n’est capable d’afficher la liste, la page se bloque. Ils sont inutilisables dans cette configuration.
Voici donc mon analyse, j’espère qu’elle peut faire avancer la résolution de ce problème qui me semble tourner autour des performances ajax…
Je vais essayer de modifier mon PR github,mais décrire tout ça en anglais, va me prendre un peu de temps
En fait j’ai été un peu vite, j’ai dû avoir une fois une réaction à 4s, mais en général cela ne change rien, je tourne en moyenne à 10s pour la sélection du produit à la douchette dans cette configuration.
Et puis aussi PRODUCT_DONOTSEARCH_ANYWHERE = 0 ou 1 ne change rien à ces performances…
MAIN_OPTIMIZE_SPEED = 1 non plus…
MAIN_DISABLE_AJAX_COMBOX = 1, à la douchette c’est n’importe quel produit qui est sélectionné sauf le bon !
concernant ces problèmes de temps de réponses, cela indique vraisemblablement que votre installation est sous Windows avec l’installation classique de DoliWamp
si c’est le cas, il faut installer WampServer, vous devriez essayer le lien suivant
Merci pour la suggestion,
mais malheureusement ce n’est pas le cas,
Ma config est sur un serveur distant tout à fait performant :
Version: 12.0.3
OS: Linux Debian 3.16.64-2 (2019-04-01) x86_64
Web server: Apache/2
PHP: PHP 5.6.40
Database: MySQL or MariaDB 5.6.48-log
Sur lequel j’ai aussi un site Magento qui n’a aucun problème de performances (mêmes technos PHP/Mysql).
Maintenant, pour l’appli Dolibarr on peut toujours ajuster des paramètres PHP via php.ini ou .htaccess si nécessaire.
Je pourrais aussi passer en PHP7 pour Dolibarr, mais le problème semble se situer côté client avec ajax.
je vois que c’est compliqué et que l’on peut y passer du temps.
Je développe des appli mobiles sur terminal code-barre (smartphone avec scanner intégré). Vous n’avez plus rien à régler, je vous active tout ce qu’il faut sur votre serveur à distance sans changer le code : cela marchera en version supérieure. L’inventaire sera mis à jour dans la base. Cela marche avec peu de réseau wifi (donc sans fils). Bien sur ce n’est plus de l’opensource et le terminal est 10 fois plus cher qu’une douchette, mais vous gagnez du temps.
Cela peut marcher avec un smartphone Android en scan par l’appareil photo mais l’opération est toujours plus lente qu’avec un vrai scanner.
Je devais faire cette appli d’inventaire : elle sera prête 1 semaine après commande
Bonjour,
c’est sans doute très bien mais par rapport à mes besoins cela me semble un peu ressembler à un rouleau compresseur pour écraser ma mouche
Pouvoir saisir des références de produits par lecteur de code à barres simple, avec des performances acceptables devrait, à mon avis, être possible partout où ça peut être nécessaire dans Dolibarr, particulièrement pour les bases riches en nombre de produits où c’est le plus utile. Cela me semble être une fonctionnalité basique.
Mais ce n’est que mon avis
J’ai trouvé une solution qui marche pour les douchettes à CR/LF (et les autres) mais je ne sais pas si elle est très élégante (il serait plus souple et plus sûr que la modif soit actionnée sur un paramètre de la fonction ajax_autocompleter) et si elle n’a pas d’effet secondaire ailleurs.
En fait il suffit de faire en sorte que le CR/LF (touche ENTER) soit ignoré.
En V12.0.3, j’ai fais ça dans /core/lib/ajax.lib.php dans function ajax_autocompleter
A partir de la ligne 68, je remplace :
$("input#search_'.$htmlname.'").keydown(function(e) {
if (e.keyCode != 9) /* If not "Tab" key */
{
console.log("Clear id previously selected for field '.$htmlname.'");
$("#'.$htmlname.'").val("");
}
});
Par le code :
$("input#search_'.$htmlname.'").keydown(function(e) {
if (e.keyCode != 9) /* If not "Tab" key */
{
if (e.keyCode == 13) {return false;} /*disable "ENTER" key Zuiko*/
console.log("Clear id previously selected for field '.$htmlname.'");
$("#'.$htmlname.'").val("");
}
});
Bien sûr j’ai gardé :les modifications du fichier /core/class/html.form.class.php :
Le seul test que j’ai fait c’est avec la donnée du module Produits
Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits
positionnée à OUI (3 caractères)
Dans ce cas les performances sont excellentes, l’affichage est instantané, qu’on fasse la sélection du produit à la main ou à la douchette. Je n’ai pas vu d’inconvénient, pour ce champ, d’ignorer la touche ENTER.
J’ai complété mon test en faisant varier cette donnée :
pour NON cela ne marche pas moins bien mais évidemment avec 10K produits les temps de latence sont insupportables.
à OUI 1 2 ou 3 caractères la réactivité est au top par contre il ne faut pas limiter le nombre de produit si non il risque de ne pas être trouvé mais ça c’est normal
Il faudrait tester dans d’autres contextes où cet ajax est employé…
