Bug 23690 - During checkout, window hangs with a pop up "Loading...you may continue scanning."
Summary: During checkout, window hangs with a pop up "Loading...you may continue scann...
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 18.11
Hardware: All All
: P5 - low major
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-27 15:28 UTC by Julie kent
Modified: 2020-06-05 00:40 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Attachments
screen shot of pop-up message "Loading...you can continue scanning." (68.85 KB, image/png)
2019-09-27 15:28 UTC, Julie kent 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Julie kent 2019-09-27 15:28:29 UTC 
Created attachment 93208 [details]
screen shot of pop-up message "Loading...you can continue scanning."

This message, whilst confounding, impedes staff from accessing other aspects of the patron record.  Our work-around has been to  advise staff to print check-out slip. Patrons with email do received an confirmation of checked out items.

However, if this is a system preference that can be removed without compromising the integrity of the patron record nor check out process, I would like to know and to know how to change the system preference. 

Please, help!
Comment 1 Owen Leonard 2019-09-27 17:04:10 UTC 
Did this behavior start after an upgrade?

Have you tried clearing your browser cache?

Do you have any custom JavaScript in the IntranetUserJS system preference?
Comment 2 Katrin Fischer 2019-10-11 05:34:11 UTC 
Hi Julie, I've tested on 18.11 and this doesn't appear to be a general problem. 

Another thing to check is your item data - make sure item type, home and holding branches are always set. Please let us know if Owen's and my suggestions didn't help you and the problem persists.

Closing the bug meanwhile.
Comment 3 David Cook 2020-06-05 00:36:00 UTC 
There is a problem related to this but the original description isn't clear enough...