Enhanced behaviour to select product on customer/supplier order to be able to use barcode reader efficiently

[zuiko]

Feature Request

[Enhanced behaviour to select product on customer order (may be supplier also?)
The first product in the list which appears, typing, some characters, must be pre-selected by default]

Use case

[On my Dolibarr 12.0.3 on customer order creation, when I begin to type some letters or numbers, some corresponding products appear but no one is selected and even if the first is correct I have to select it by my mouse and not typing ENTER.
This behaviour make my barcode reader unusable when it send CR/LF end of line characters]

[On this demo site with the same Dolibarr level the behaviour is completely different and the first line is selected, so you can type ENTER and that is]

[I don't know if they changed something on their Dolibarr but I think this behaviour is much more better for productivity purpose.
Could it be possible to get systematically this behaviour on Dolibarr?
May be is there some parameter somewhere to do that? But I did not find it.
May be it's something different on javascript?]

Discussion on French forum here

[StephaneLesage]

You don't need the mouse. You can use the down arrow on your keyboard.
But of course it would be better if it selects the first product when exiting with TAB or ENTER.

[zuiko]

Yes, down arrow works but not with the barcode reader ;)

[frederic34]

I post an answer on forum how to autoselect if only one choice without tab enter etc

[zuiko]

Thanks to frederic34, I continued my investigations...
This morning I have been thinking about the impact of the product module settings on the product research of the customer order.
I restored the code to its original state:(PRODUCT_USE_SEARCH_TO_SELECT, 0,) (file /htdocs/core/class/htmlform.class.php).
I used the Firefox browser [83.0 (64 bits)].
In the automatic barcode generation, I set the default EAN13 mask to 020{00000000} (on 13 characters because my codes have 13 characters. This not a good idea for another reason: the generated code will be false, but this is an other history and I write an other PR...
The main factor of my problems is still the number of products 10890 exactly...
In the configuration of the products module,
if the parameter : Wait until you have pressed a key before loading the contents of the product drop-down list = NO
and if the parameter: Maximum number of products in the drop-down lists = 0
In commerce, entering a sales order, when clicking in the field Predefined Products/Services on sale :

1. the list in ajax is displayed in 5 to 6 seconds,
2. the seizure, then, of a barcode by hand shower with CR/LF triggers well the selection of the good product but at the end of 11 seconds of waiting !!! Which is absolutely unbearable.

But functionally it is perfect.

Then any change in the product module's parameters causes the complete malfunction of the barcode entry by hand shower.
For example if the parameter :
Wait until you have pressed a key before loading the contents of the product drop-down list = YES (whatever the nb of characters chosen from 1 to 3),
If you leave the parameter: Maximum number of products in the drop-down lists at 0

• When you try to enter a barcode (the same one) with the hand shower (with CR/LF), nothing is ever selected. It seems that it goes too fast for the system (the CR/LF is valid before the selection is made).
• If you do the same input by hand (or by copy/paste), therefore slower, the selection will end up being made quickly but, without the patch, the enter key is inoperative, you have to scroll down to the single product with the down arrow on the keyboard or make the selection with the mouse.
• If I apply the patch :(PRODUCT_USE_SEARCH_TO_SELECT, 1,) to the 2 lines (file /htdocs/core/class/htmlform.class.php, lines 2045 and 2797), the barcode entered by hand (or copied/pasted) is quickly replaced by the product reference on the line itself and the enter key is effective and moves to the next field. But nothing to do so that a hand shower (with CR/LF, I have only that at hand today), has the same efficiency, the barcode disappears after the CR/LF and that's it.
• If we change the parameter: Maximum number of products in the drop-down lists to something other than 0 (500 for example) the barcode may not be found and is rejected (no record found) .

If, with the patch, I go back to my original configuration, the performances are not really better (4s for the ajax list + around 10s for the product to be selected, with a barcode reader with CR/LF).

I made tests on Chrome and Edge, in the case of the display of all the products by ajax. Here it's just worse, neither of them is able to display the list, the page gets stuck. They are unusable in this configuration.

And then also

• PRODUCT_DONOTSEARCH_ANYWHERE = 0 or 1 does not change anything to these performances...
• MAIN_OPTIMIZE_SPEED = 1 either...
• MAIN_DISABLE_AJAX_COMBOX = 1, with the showerhead it is any product which is selected except the good one!

Precision, my config is:
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

So here is my analysis, I hope it can help to solve this problem which seems to me to revolve around ajax performances for a wide range of products (>10K)...

[zuiko]

I found a solution that works for CR/LF showerheads (and others) but I don't know if it's very elegant (it would be more flexible and safer if the change is activated on a parameter of the ajax_autocompleter function) and if it has no side effect elsewhere.
In fact, just make sure that the CR/LF (ENTER key) is ignored.
In V12.0.3, I did this in /core/lib/ajax.lib.php in function ajax_autocompleter
From line 68, I replaced:
$("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(""); } });
by the 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(""); } });

Of course I kept the modifications of the /core/class/html.form.class.php file.

On ligne 2045 replaced 0 by 1
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.’/product/ajax/products.php’, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);

On ligne 2797 replaced 0 by 1
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.’/product/ajax/products.php’, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);

The only test I did was with the data from the Products module:
Wait until you have pressed a key before loading the contents of the product drop-down list.
set to YES (3 characters)

In this case the performance is excellent, the display is instantaneous (even for more than 10K products), whether you select the product by hand or with the hand shower. I did not see any disadvantage, for this field, to ignore the ENTER key.

To be tested/advanced, therefore...

[zuiko]

For information some have developped some free dedicated libraries for barcode readers.

[eldy]

Please check if commit 85bb3fa is enough.
Reopen and comment if not.

[zuiko]

Hi eldy,
In fact with 0, the combo remains... I just tested it.
If you don't change the parameter 0 to 1 into ajax_autocompleter the input is slower if the product is unique (by hand as with a barcode reader). Indeed, the input line remains filled with the barcode and ajax displays below the product to be selected. You have to click with the mouse or tap the down arrow on the keyboard to replace the barcode with the product code.
If the parameter is at 1, as soon as the barcode is complete, it is replaced on the same line by the product code, no further action is necessary. The speed is better.
When you do a lot during the day this small difference in ergonomics can be felt.

but my users gave me this testimony: the value 1 for select is relevant for entering customer orders with a barcode reader, but it is less relevant for entering supplier orders (which are not usually entered by hand shower), because the combo gives verification information which then disappears.This is especially true for the purchase price, which is not pre-filled in the box (is this voluntary?).

So on my side, I would keep select = 1 for customer orders and select = 0 for supplier orders.

For the moment, I didn't found how to reopen a closed pull request, sorry, I try ;-)

Some screenshots:
select = 0

select=1