http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 23364 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23364&action=edit Bug 11360 - Disable barcode field and submit button when a hold is found At the moment when scanning in returns, it can be easy to miss a hold trap due to the fact that the barcode and submit are still active and the barcode field is focused on. A librarian who is focused on scanning can easily scan another item and pass over the form, which is equivalent to clicking the "ignore" button. Test Plan: 1) Place a hold on an item 2) Scan that item's barcode though returns.pl 3) Note the hold trap 4) Scan another barcode 5) Note you were able to bypass interacting with the trapped hold form 6) Apply this patch 7) Repeat steps 2-4 8) Note you must now click one of the buttons. Clicking ignore will allow you to continue scanning items as before. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 sandboxes@biblibre.com <sandboxes@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23364|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- Looks good. I tested in a sandbox and it did what was expected. Hold trap failed before the patch applied, and then the hold trap worked after. I like that the barcode field is completely deactivated, rather than the hold trap just taking the focus off. This forces you to push a button. Our current jquery that addresses this just takes the focus off. We tossed around the idea of deactivating the barcode field altogether, but didn't have the nerve to do that much. I think the behavior is acceptable and expected. Christopher -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 --- Comment #6 from Christopher Brannon <cbrannon@cdalibrary.org> --- Owen, Can you provide any examples of when the field is hidden? I was unaware it did this. Maybe I have not been in a circumstance that it has. Christopher -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA CC| |jonathan.druart@biblibre.co | |m QA Contact|testopia@bugs.koha-communit |jonathan.druart@biblibre.co |y.org |m --- Comment #8 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to Owen Leonard from comment #5)

Is there any reason to show the input field at all if it's disabled? We are inconsistent on the checkout page. Sometimes the input is displayed as disabled, sometimes it is hidden. I think we should stick with hiding the input (and the "options" checkboxes too in this case) if the user cannot interact with them.

Owen, could you explain this point please? This patch impacts the check-in page and I don't know where there is hidden fields. To me it is consistent to disable the input and the submit button here. (In reply to Liz Rea from comment #7)

putting the hold notification in a modal window might be nice here as well - something that greys the screen and puts the hold notice on top (with a non-js fallback, of course)

It is out-of-the-scope of this bug. Maybe could you open a new report for that? Marked as Passed QA. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #10 from Galen Charlton <gmcharlt@gmail.com> --- This patch can lead to a situation where the barcode form and button is disabled without providing the staff member any way of enabling it (short of use the back button or the like). Specifically, this occurs if an item that does /not/ fill a hold and which does not already have an active branchtransfer record is checked in a library other than its home. The staff member can print a transfer slip, but doing so does not enable the barcode input form. Marking as failed QA. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 --- Comment #12 from Christopher Brannon <cbrannon@cdalibrary.org> --- There are a couple approaches you could go from here. Currently we have a jquery setup that simply takes the focus off the input box. It doesn't disable anything. This has been a successful adjustment for us. You might think that this is a loose fix, as you can click on the text box and continue on, but it is really no different than clicking the ignore button. The other approach is to fix the patch to re-enable the input box and button for transfers. I don't know if it is worth going to a modal dialog window in this one function. It isn't a consistent workflow throughout Koha. When you start to do things differently in different parts of the software, it really breaks down workflow. I think modal dialog windows would be great for many alert messages throughout Koha, but it needs to be consistent throughout, otherwise workflow is disrupted, and you might look for these alerts one way and not the other. Christopher -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 --- Comment #14 from Kyle M Hall <kyle@bywatersolutions.com> ---

I agree about consistency, but from the other direction: namely, Bootstrap modals are only used in a couple places currently, but if folks generally think that they're a good direction to go in, then circulation is a good place to get started with adding more use of them: it's faster for a circ operator to dismiss a modal than to wait for a round-trip to the server with the current approach for dealing with blocking alerts during circ operations.

I concur! -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23511|0 |1 is obsolete| | --- Comment #15 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 44967 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=44967&action=edit Bug 11360 - Disable barcode field and submit button when a hold is found At the moment when scanning in returns, it can be easy to miss a hold trap due to the fact that the barcode and submit are still active and the barcode field is focused on. A librarian who is focused on scanning can easily scan another item and pass over the form, which is equivalent to clicking the "ignore" button. Test Plan: 1) Apply this patch 2) Trap a hold, note the new modal 3) Check the hold in a second time 4) Note the new modal 5) For each modal, test each button -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com, | |nicole@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #17 from Nick Clemens <nick@bywatersolutions.com> --- To be more clear: Failing QA because the input box is still selected and active while the modal is up. Typing a barcode and pressing enter (i.e. scanning the next book) will check in the next item without taking any action on the hold which is the same behavior as before patch. The modal does look very nice though and buttons seem to work as expected -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44967|0 |1 is obsolete| | --- Comment #18 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 45038 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45038&action=edit Bug 11360 - Disable barcode field and submit button when a hold is found At the moment when scanning in returns, it can be easy to miss a hold trap due to the fact that the barcode and submit are still active and the barcode field is focused on. A librarian who is focused on scanning can easily scan another item and pass over the form, which is equivalent to clicking the "ignore" button. Test Plan: 1) Apply this patch 2) Trap a hold, note the new modal 3) Check the hold in a second time 4) Note the new modal 5) For each modal, test each button -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #20 from Owen Leonard <oleonard@myacpl.org> --- If a checkin triggers the modal, any messages or alerts which were also triggered by the checkin will be hidden by the modal and will disappear after clearing the modal. For instance: A warning that the item was not checked out, or a checkin message which has been configured for that particular item type. If libraries are concerned about seeing the "not checked out" message this is problematic since Bug 14821 now blocks those transactions from appearing in the table of scanned items. And while I don't personally know what the checkin message option is used for, I don't think it's acceptable that it disappears. Perhaps those messages should not be cleared when the modal is dismissed? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 --- Comment #22 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Owen Leonard from comment #21)

Created attachment 45122 [details] Screenshot of layout issues

This screenshot highlights a few markup/layout issues:

- The list which displays the patron information is missing the enclosing <ul></ul> - The list shouldn't be centered. There is CSS at line 1225 of staff-global.css which aligns lists which are displayed in a message div. It should be expanded to include '.modal-body ul'

I removed the ul tags to make it readable. The ul styling was 'odd'. Would you be able to style the data? My css-fu isn't all that great ; )

- The layout of the buttons doesn't work, but I'm not sure what to do about that.

That's really odd, because they look great on my system! Are you using any styling beyond stock Koha on your test system? -- You are receiving this mail because: You are watching all bug changes.