[Bug 42505] New: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Bug ID: 42505 Summary: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal 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 When returning an item required to fulfil a hold at another branch, with HoldsAutoFill set to 'Don't', the 'Hold found' modal (returns.tt: hold-found-modal / hold-found2 in older versions) is displayed and the librarian must choose 'Confirm hold and transfer' or 'Print slip, transfer, and confirm'. If the librarian clicks the print variant, the slip is opened via window.open() (Dopop()) called from $(document).ready on the page that loads *after* the form submission to confirm the hold. Because the window.open() call happens during a fresh page load, it is not associated with a user gesture, and modern browsers block it as an unsolicited popup. This affects the same code path used for HoldsAutoFill + HoldsAutoFillPrintSlip: the slip popup is fired on document.ready of the response page, with the same popup-blocker risk. Steps to reproduce ================== 1. Set HoldsAutoFill = Don't. 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. The 'Hold found' modal appears. 5. Click 'Print slip, transfer, and confirm'. Expected: the hold is confirmed and the hold transfer slip opens in a new window. Actual: the form submits and the hold is confirmed, but the slip popup is blocked by the browser. The librarian sees no slip and may not realise the slip was attempted. Root cause ========== In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print click handler sets a hidden input print_slip=1 and submits the form. The server (circ/returns.pl) sets the print_slip template parameter on the response, and the response page calls Dopop() (window.open) on document.ready. That window.open() is not within a user gesture event, so popup blockers reject it. Suggested fix ============= Open the print window synchronously inside the .print click handler, while the user gesture is still active. The reserve_id is already present in the modal form as a hidden input, and hold-transfer-slip.pl needs only the reserve_id; the slip content does not depend on the hold having been moved to Waiting state. The form submit to confirm the hold then proceeds in the main window as before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198402 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198402&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: West Sussex Library Service Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Comma delimited| |OpenFifth list of Sponsors| |<https://openfifth.co.uk/> Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch Sponsorship status|--- |Sponsored -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198402|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198403 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198403&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42506 Blocks| |42507 Status|Needs Signoff |Signed Off Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42506 [Bug 42506] Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42507 [Bug 42507] Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198403|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 199178 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199178&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |lucas@bywatersolutions.com --- Comment #4 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Martin Renvoize (ashimema) from comment #3)
Created attachment 199178 [details] [review] Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker
When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted.
This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct.
To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too.
Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
In step 1 the test plan is set HoldsAutoFill = "Don't". In step 8 it is Repeat with HoldsAutoFill = "Don't". Can you clarify the test plan here? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Re QA question about the test plan (step 1 vs step 8 both setting HoldsAutoFill = "Don't"): This is intentional, not a copy/paste error. HoldsAutoFill controls whether the "Hold found" modal (which contains the "Print slip..." button this patch fixes) appears at all: - If HoldsAutoFill = "Do", the hold is auto-filled/transferred silently and the modal never appears, so the patched code path isn't exercised at all. - So HoldsAutoFill must stay "Don't" for both steps 1-7 and step 8 - there's no second syspref value being tested here. What differs between the two is the *hold scenario*, not the syspref: - Steps 2-7: pickup branch differs from the checkin branch -> "transfertodo" is true -> modal shows "Print slip, transfer, and confirm" - Step 8: pickup branch is the *same* as the checkin branch -> "transfertodo" is false -> modal shows "Print slip and confirm" instead Both buttons share the same click handler this patch touches (returns.tt), so step 8 is there to cover that second button/scenario, not a different HoldsAutoFill value. Happy to reword the commit's test plan if that would help future QA - let me know. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |Laura.escamilla@bywatersolu |y.org |tions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Laura Escamilla <Laura.escamilla@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Laura Escamilla <Laura.escamilla@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199178|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #6 from Laura Escamilla <Laura.escamilla@bywatersolutions.com> --- Created attachment 206255 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206255&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #7 from Laura Escamilla <Laura.escamilla@bywatersolutions.com> --- QA'd successfully. Tested with HoldsAutoFill = Don't for both different-branch and same-branch holds. Confirmed that the appropriate print slip opens in a separate window without being blocked by the browser, and that the hold is correctly confirmed. For the different-branch scenario, confirmed the item is placed in transit as expected. No regressions found. Passed QA. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA CC| |pedro.amorim@openfifth.co.u | |k --- Comment #8 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hi all, On a 'Next available' hold the item isn't attached yet at that point, so the slip prints without a barcode. 1) Without the patch, place a 'Next available' hold for Henry Acevedo: http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=76&borrowernumber=19 2) Check in 39999000003154 at http://localhost:8081/cgi-bin/koha/circ/returns.pl and click 'Print slip and confirm' 3) The slip shows the barcode 4) Apply the patch, cancel the hold, and repeat 1-2 5) The slip has no barcode -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206255|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206819 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206819&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206820 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206820&action=edit Bug 42505: (follow-up) Fix missing barcode on Next available hold slip QA feedback: opening the hold transfer slip synchronously (in the click handler, before the checkin form submits) means the reserve is not yet confirmed at that point. For a "Next available" hold, the reserve has no itemnumber attached until confirmation, so ReserveSlip had nothing to look up a barcode with and the slip printed blank. ReserveSlip already accepted an itemnumber as a fallback for this case, but hold-transfer-slip.pl never passed one through. Pass the checked-in item's number from the confirm form as that fallback, both from returns.tt's .print handler and through to ReserveSlip. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a "Next available" (not item-specific) hold. 3. Check in an item that fills that hold. 4. Click "Print slip and confirm" in the "Hold found" modal. 5. Confirm the slip shows the checked-in item's barcode. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Great catch there Pedro, thanks. :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206820|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #12 from Slava Shishkin <slavashishkin@gmail.com> --- Created attachment 206836 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206836&action=edit Bug 42505: (follow-up) Fix missing barcode on Next available hold slip QA feedback: opening the hold transfer slip synchronously (in the click handler, before the checkin form submits) means the reserve is not yet confirmed at that point. For a "Next available" hold, the reserve has no itemnumber attached until confirmation, so ReserveSlip had nothing to look up a barcode with and the slip printed blank. ReserveSlip already accepted an itemnumber as a fallback for this case, but hold-transfer-slip.pl never passed one through. Pass the checked-in item's number from the confirm form as that fallback, both from returns.tt's .print handler and through to ReserveSlip. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a "Next available" (not item-specific) hold. 3. Check in an item that fills that hold. 4. Click "Print slip and confirm" in the "Hold found" modal. 5. Confirm the slip shows the checked-in item's barcode. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Slava Shishkin <slavashishkin@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #13 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hey! Thanks for the follow-up, the barcode now shows on 'Next available' holds. However, it appears the root cause of the problem is not fixed and the slip is still generated before the hold is confirmed, so anything set at confirmation is missing from it, e.g. the waiting date: 1) Edit HOLD_SLIP: http://localhost:8081/cgi-bin/koha/tools/letter.pl?op=add_form&branchcode=&module=circulation&code=HOLD_SLIP 2) In the 'Email' message body, add a new line, and save: Waiting since: [% hold.waitingdate | $KohaDates %] 3) Place a 'Next available' hold for Henry Acevedo, pickup at Centerville: http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=76&borrowernumber=19 4) Check in 39999000003154 at Centerville and click 'Print slip and confirm': http://localhost:8081/cgi-bin/koha/circ/returns.pl => Expected: 'Waiting since: <today>' => Actual: 'Waiting since:' is blank 5) Reload the slip popup => 'Waiting since: <today>' now appears, because the hold was only confirmed after the slip was generated -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |slavashishkin@gmail.com --- Comment #14 from Slava Shishkin <slavashishkin@gmail.com> --- Thanks Pedro, I reproduced the issue from comment 13. The barcode follow-up fixed one symptom, but the slip was still rendered before ModReserveAffect() confirmed the hold. This meant fields updated during confirmation, such as waitingdate and expirationdate, were missing or stale on the first print. This follow-up opens a blank named popup during the user gesture, then submits the confirmation form. The response page loads the slip into the same popup only after the hold has been updated. This preserves the popup blocker fix without passing individual reserve fields as workarounds. Tested manually with a title-level "Next available" hold: - the popup was not blocked; - the first slip contained the checked-in item's barcode; - the first slip showed today's waiting date; - the Waiting hold expiration date was correct; - reloading the slip produced the same values. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #15 from Slava Shishkin <slavashishkin@gmail.com> --- Created attachment 206896 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206896&action=edit Bug 42505: (follow-up) Generate hold slip after confirming hold The previous follow-up passed the checked-in itemnumber to the slip, but the slip was still rendered before ModReserveAffect() confirmed the hold. Fields updated during confirmation, such as waitingdate and expirationdate, were therefore missing or stale on the first print. Open a blank named popup during the user gesture, then submit the confirmation form with print_slip set. The response page reuses that popup after the hold has been updated. This preserves the popup blocker fix and allows ReserveSlip() to use the persisted hold and item data without passing individual fields as workarounds. To test: 1. Set HoldsAutoFill to "Don't". 2. Add the following to the HOLD_SLIP notice: Waiting since: [% hold.waitingdate | $KohaDates %] Barcode: <<items.barcode>> 3. Place a title-level "Next available" hold with pickup at the check-in library. 4. Check in a matching item. 5. Click "Print slip and confirm". 6. Confirm the popup is not blocked. 7. Confirm the first slip contains the item's barcode and today's waiting date. 8. Reload the slip and confirm the values are unchanged. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206836|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #16 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thanks everyone! Pushed to main for 26.11! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org