[Bug 42506] New: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42506 Bug ID: 42506 Summary: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Depends on: 42505 With HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do", a check-in that traps a hold for another branch silently confirms the hold and places the item in transit. The hold transfer slip is then meant to open automatically. The slip is opened via Dopop() / window.open() called from $(document).ready on the response page (koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt, near the 'if (print_slip)' block). Because that window.open() runs after a fresh page load and is not associated with a user gesture, modern browsers commonly block it as an unsolicited popup. The hold is confirmed, the item is in transit, but the librarian sees no slip. This is the auto-fill counterpart to bug 42505. Bug 42505 fixes the manual click path by opening the slip synchronously in the .print click handler. The auto-fill path has no click handler to attach to, so it needs a different solution. Possible approaches =================== 1. Render an inline 'Print slip' button (or banner with a button) on the response page when print_slip is set, and let the librarian click it to open the slip. The user gesture then drives window.open() and is not blocked. 2. Render the slip inline on the response page, perhaps inside an iframe, and trigger window.print() from inside that iframe. 3. Stop using window.open() for the slip and switch to a same-window print mechanism using a hidden iframe + content.print(). Reproduction ============ 1. Set HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do". 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. Expected: hold is auto-confirmed, item placed in transit, slip opens in a new window. 5. Actual: hold is auto-confirmed and item placed in transit, but the slip popup is blocked by the browser. Depends on bug 42505 because the chosen approach for one path may inform the other (the manual click fix in 42505 keeps Dopop()/window.open() but moves it inside the gesture; this auto-fill path may need a more fundamental change away from that pattern). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 [Bug 42505] Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org