in orderreceive when you receive an order with 'AcqCreateItem ' on 'receiving', you must first fill the 'Item' block and validating by clicking 'add' before clicking the 'save' button. Using a scan machine is like typing 'enter' and saving this receive, it is unwanted. For serials-edit it's the same problem. So this patch do the same in the two pages. To test: You must have a barcode scan... ;o) Or try to type enter without the patch, it's what the scan machine sends. thx
Created attachment 12392 [details] [review] proposed patch thx for testing
Created attachment 12393 [details] [review] proposed patch
I can confirm the behaviour without patch. However the patch does not longer apply: error: patch failed: koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-edit.tt:422 error: koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-edit.tt: patch does not apply Marc
Created attachment 12689 [details] [review] Bug-8557-Prevents-form-validation-by-pressing-Enter.patch Rebased patch. Could you test now?
Created attachment 12702 [details] [review] [SIGNED-OFF] Bug 8557: Prevents form validation by pressing "Enter" this patch prevents a scan machine to send 'enter' to the form when it is not expected. The patch is on orderreceive.tt and serials-edit.tt. Written by Alex Arnaud. MT6626. Signed-off-by: Marc Veron <veron@veron.ch> Tested with receiving orders and receiving serials. Could reporduce problem befor applying the patch. After applying the patch both forms behaved as expected.
Created attachment 13167 [details] pic
(In reply to comment #0) > in orderreceive when you receive an order with 'AcqCreateItem ' on > 'receiving', you must first fill the 'Item' block and validating by clicking > 'add' before clicking the 'save' button. > Using a scan machine is like typing 'enter' and saving this receive, it is > unwanted. > For serials-edit it's the same problem. > So this patch do the same in the two pages. > To test: > You must have a barcode scan... ;o) > Or try to type enter without the patch, it's what the scan machine sends. hmmm, i need more info to QA this patch... do i need to scan a barcode in the 'barcode' field to test this patch? if i do this, the 'enter' key *is* detected and the form is saved, so the patch does not seem to work (in chrome-osx)? i have added a screenshot to explain what i am testing (the barcode field)
Created attachment 13247 [details] snapshot without patch Hello James, in fact, I have pasted a snapshot. Without the patch if you hit "enter" in the orderreceive page, the form is submited, in my case I have not filled a requested field in order to make this state more visible. So, James, you don't need a scan machine, the machine sends a "enter" to koha. Without the patch if you hit enter (the same action than a scan) the form is submitted, what we need is that the scanning doesn't send the form. With the patch if you hit "enter" nothing happens, it's what we expect. Thx
Created attachment 13660 [details] [review] [SIGNED-OFF] Bug 8557: Prevents form validation by pressing "Enter" this patch prevents a scan machine to send 'enter' to the form when it is not expected. The patch is on orderreceive.tt and serials-edit.tt. Written by Alex Arnaud. MT6626. Signed-off-by: Marc Veron <veron@veron.ch> Tested with receiving orders and receiving serials. Could reporduce problem befor applying the patch. After applying the patch both forms behaved as expected. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Checked order receive and serials edit page, barcode + enter does no longer submit the form. All tests pass.
Could someone please confirm that there is no situation where a library would want Enter to automatically save the barcode? If that is a feature that libraries might be using, I am loth to remove it entirely.
I think it's consistent with other item forms (cataloguing) this way and is more like the expected behaviour.
I agree with Katrin.
I was thinking about this. Maybe a good rule of thumb could be: if the barcode field is one of many fields (data entry) we don't want it to submit the form, but when it's only a barcode field we want it to. Would that make sense?
Makes sense!
I do not see any "Add" button nor anywhere to edit items on the order receive page on current master. I see a table with a list of items, and there are links to take me to edit the items, but hitting enter in the barcode field on those screens does not do anything. Please provide a detailed test plan covering the entire workflow I should be following, starting at the VERY beginning, so that I can test this.
Created attachment 13749 [details] Screenshot unwanted return while adding item during receiving process 1) Set syspref 'AcqCreateItem' to 'Create Item when receiving an order.' 2) Create a basket for a vendor, add an order line. 3) Search for this vendor using Vendor search 4) Receive Shipment for this vendor and choose the title you ordered in 2) 5) You will get the dialog to create related item(s) 6) Fill in Item 0 through o (see screenshot) 7) Scan Barcode for field p - Barcode 7) Result: Scanner sends a [return], form closes and you had no chance to fill in fields t - z
Created attachment 13750 [details] [review] [SIGNED-OFF] Bug 8641 [Follow up]-Reword warning about log-in as root user to About-System information The wording of this message sounds strange to a native speaker. Reword it. Signed-off-by: Marc Veron <veron@veron.ch> New wording appears as expected on about page.
Comment on attachment 13750 [details] [review] [SIGNED-OFF] Bug 8641 [Follow up]-Reword warning about log-in as root user to About-System information Sorry, mistaked with bug number...
This patch has been pushed to master. Marc, thank you for the detailed test plan. As a note, I observe that this still does not work quite right in Chrome
(In reply to comment #19) > This patch has been pushed to master. Marc, thank you for the detailed test > plan. > As a note, I observe that this still does not work quite right in Chrome ... which is submitting a different form when you hit the "Enter" key. It works perfectly in FF, though.
Pushed to 3.10.x, will be in 3.10.1
Created attachment 14019 [details] [review] Bug 8557 - Unexpected behavior with scanners This is an alternative to the original implementation - this one works in chrome as well as firefox. To test: 1) Set syspref 'AcqCreateItem' to 'Create Item when receiving an order.' 2) Create a basket for a vendor, add an order line. 3) Search for this vendor using Vendor search 4) Receive Shipment for this vendor and choose the title you ordered in 2) 5) You will get the dialog to create related item(s) 6) Fill in Item 0 through o (see screenshot) 7) Scan Barcode for field p - Barcode 7) Result: Scanner sends a [return], form closes and you had no chance to fill in fields t - z
Created attachment 14325 [details] [review] Bug 8557 - Unexpected behavior with scanners This is an alternative to the original implementation - this one works in chrome as well as firefox. To test: 1) Set syspref 'AcqCreateItem' to 'Create Item when receiving an order.' 2) Create a basket for a vendor, add an order line. 3) Search for this vendor using Vendor search 4) Receive Shipment for this vendor and choose the title you ordered in 2) 5) You will get the dialog to create related item(s) 6) Fill in Item 0 through o (see screenshot) 7) Scan Barcode for field p - Barcode 7) Result: Scanner sends a [return], form closes and you had no chance to fill in fields t - z Signed-off-by: Marc Veron <veron@veron.ch> Testted with Chrome Version 23.0.1271.97 m and Firefox 17.0.1, both behave as expected.
Created attachment 14556 [details] [review] [SIGNED-OFF] Bug 8557 - Unexpected behavior with scanners This is an alternative to the original implementation - this one works in chrome as well as firefox. To test: 1) Set syspref 'AcqCreateItem' to 'Create Item when receiving an order.' 2) Create a basket for a vendor, add an order line. 3) Search for this vendor using Vendor search 4) Receive Shipment for this vendor and choose the title you ordered in 2) 5) You will get the dialog to create related item(s) 6) Fill in Item 0 through o (see screenshot) 7) Scan Barcode for field p - Barcode 7) Result: Scanner sends a [return], form closes and you had no chance to fill in fields t - z Signed-off-by: Marc Veron <veron@veron.ch> Tested with Chrome Version 23.0.1271.97 m and Firefox 17.0.1, both behave as expected. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Tested with Firefox and Chromium in Ubuntu. Additional test done: 1) Add a new subscription, choose 'receive adds items' 2) Receive an issue, fill out $p with a barcode 3) Make sure hitting enter in the barcode field does not send the form. All tests pass and QA script pass.
This patch has been pushed to master.
Pushed to 3.10.x will be in 3.10.2