[Bug 41705] New: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Bug ID: 41705 Summary: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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: black23@gmail.com, fridolin.somers@biblibre.com, gmcharlt@gmail.com, koha-bugs@lists.koha-community.org, kyle@bywatersolutions.com, lisette@bywatersolutions.com, martin.renvoize@openfifth.co.uk, maryse.simard@inlibro.com, testopia@bugs.koha-community.org Depends on: 23228, 23461 Blocks: 13985 The pattern we use for automatically printing receipts and slips can often trigger popup blockers. This is because we trigger the popup window via JavaScript after page reload and this is interpreted as not being a user directed event and thus invokes many browsers popup blocking code. We could reverse our process such that the form submission itself has a target="_blank" attribute to trigger the popup at form submission time (which is a direct user action), then our controller handles the post, redirect, get pattern for printing. We fires the window print in the already opened new tab and finally close the tab, thus bringing the original tab back into focus, after print. This would need a little thought regarding the original tab, as we'd need the reset that tabs context/state as part of the initial submit that triggers the popup earlier in the process. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] [Omnibus] Cash Management - Koha as 'Point of Sale' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 [Bug 23228] Add option to automatically display payment receipt for printing after making a payment https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23461 [Bug 23461] Popup blockers triggered by option to automatically display payment receipt for printing after making a payment -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 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 the assignee for the bug. You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 192000 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192000&action=edit Bug 41705: Upgrade POS receipt printing to use PRG pattern This commit implements a POST-Redirect-GET (PRG) pattern for the Point of Sale. We also reverse the receipt printing workflow to make it popup-safe when using FinePaymentAutoPopup. - When FinePaymentAutoPopup is enabled, the POS form submits to a new tab - The server processes the payment and redirects to the receipt print page - The receipt page auto-prints and attempts to close itself - When FinePaymentAutoPopup is disabled, the original in-page flow is preserved - Added error handling for missing receipts - Modernized JavaScript printing logic - Added manual print and close buttons to receipt page Test Plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale page and complete a sale 3. Confirm the receipt opens in a new tab and auto-prints 4. Close the receipt tab and verify the POS page is ready for next transaction 5. Disable FinePaymentAutoPopup system preference 6. Complete another sale 7. Verify the POS page reloads with 'Print receipt' and 'Email receipt' buttons 8. Click 'Print receipt' and verify it opens in a new tab 9. Test error case: manually modify receipt URL and verify error message displays -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |normal -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Severity|normal |minor -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |david@davidnind.com --- Comment #2 from David Nind <david@davidnind.com> --- I'm getting these errors: 1. With FinePaymentAutoPopup set to "Do": Can't locate object method "uri_for" via package "C4::Context" at /kohadevbox/koha/pos/pay.pl line 84. at /kohadevbox/koha/pos/pay.pl line 82 2. With FinePaymentAutoPopup set to "Don't": Can't locate object method "uri_for" via package "C4::Context" at /kohadevbox/koha/pos/pay.pl line 92 Testing notes (using KTD): 1. Apply the patch. 2. Rebuild: yarn build 3. Restart: restart_all 4. EnablePointOfSale set to "Enable" 5. UseCashRegisters set to "Use" 6. Create a cash register: Administration > Accounting > Cash registers 7. Add a debit type: Administration > Accounting > Debit types -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff Patch complexity|--- |Small patch -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197337 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197337&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192000|0 |1 is obsolete| | Attachment #197337|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197338 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197338&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Sorry it took me so long to come back here David. Many thanks for the testing.. it looked like I'd missed a few parts in the commit. I've cleaned up a bit now and submitted a new patch with a, hopefully, clearer test plan too. -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197338|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #6 from David Nind <david@davidnind.com> --- Created attachment 197544 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197544&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #7 from David Nind <david@davidnind.com> --- Created attachment 197545 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197545&action=edit Print receipt example - showing print receipt and close buttons I have signed-off, as things in the test plan work. However, when printing (I printed to PDF) the "Print receipt" and "Close " buttons appear on the receipt, which I don't think should happen. Note: Using a Chrome-based browser, I enabled the "Don't allow sites to send pop-ups or use redirects". -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197544|0 |1 is obsolete| | -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198404 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198404&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198405 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198405&action=edit Bug 41705: (follow-up) Hide receipt page buttons when printing The Print receipt and Close buttons added in the previous patch use class="no-print", but printreceiptinvoice.css had no @media print rule for that class — so they appeared in the printed output (e.g. when saving as PDF or auto-printing in browsers that block popups). Add a @media print rule so the buttons remain visible on screen but disappear from the printed receipt. Test plan: 1. Disable browser popups (Chrome: "Don't allow sites to send pop-ups or use redirects"). 2. Enable FinePaymentAutoPopup. 3. Complete a POS sale. 4. On the receipt page, choose Print to PDF (or trigger auto-print). 5. Verify the printed/PDF output contains only the receipt body — no Print receipt or Close buttons. 6. Verify the buttons remain visible on screen. -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|--- |Sponsored Comma delimited| |OpenFifth list of Sponsors| |<https://openfifth.co.uk/> -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198404|0 |1 is obsolete| | Attachment #198405|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198406 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198406&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198407 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198407&action=edit Bug 41705: (follow-up) Hide receipt page buttons when printing The Print receipt and Close buttons added in the previous patch use class="no-print", but printreceiptinvoice.css had no @media print rule for that class — so they appeared in the printed output (e.g. when saving as PDF or auto-printing in browsers that block popups). Add a @media print rule so the buttons remain visible on screen but disappear from the printed receipt. Test plan: 1. Disable browser popups (Chrome: "Don't allow sites to send pop-ups or use redirects"). 2. Enable FinePaymentAutoPopup. 3. Complete a POS sale. 4. On the receipt page, choose Print to PDF (or trigger auto-print). 5. Verify the printed/PDF output contains only the receipt body — no Print receipt or Close buttons. 6. Verify the buttons remain visible on screen. -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198406|0 |1 is obsolete| | -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198407|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #12 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 198415 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198415&action=edit Bug 41705: Use PRG pattern for POS receipt printing to avoid popup blockers The previous approach triggered popup blockers because the receipt window was opened via JavaScript after a page reload — browsers treat this as a non-user-initiated action. This patch reverses the flow: when FinePaymentAutoPopup is enabled, the payment form submits directly to a new tab via target="_blank" (a user-initiated action that browsers allow), the server processes the payment and redirects (303) to the receipt page, which auto-prints and closes itself, returning focus to the POS tab. When FinePaymentAutoPopup is disabled, the server redirects back to the POS page with payment details in the URL (standard PRG), displaying the existing success banner with print/email receipt buttons. Changes: - pos/pay.pl: Implement PRG redirect for both popup and non-popup flows, URI-encode redirect parameters, remove session-based state management - pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled, reset form state after submission via same-scope setTimeout - pos/printreceipt.pl: Add error handling for missing receipts, pass autoprint parameter to template - pos/printreceipt.tt: Add conditional auto-print, manual print/close buttons, error display, and IntranetSlipPrinterJS preference support - slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete Chrome setTimeout hack Test plan: 1. Enable FinePaymentAutoPopup system preference 2. Go to Point of Sale, add items, and complete a sale 3. Verify receipt opens in a new tab without popup blocker warnings 4. Verify receipt auto-prints and tab closes after printing 5. Verify original POS tab form is reset for next transaction 6. Disable FinePaymentAutoPopup 7. Complete another sale 8. Verify POS page shows success with Print/Email receipt buttons 9. Test receipt printing from other pages (circulation, fees) to confirm slip-print.inc change causes no regressions Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #13 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 198416 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198416&action=edit Bug 41705: (follow-up) Hide receipt page buttons when printing The Print receipt and Close buttons added in the previous patch use class="no-print", but printreceiptinvoice.css had no @media print rule for that class — so they appeared in the printed output (e.g. when saving as PDF or auto-printing in browsers that block popups). Add a @media print rule so the buttons remain visible on screen but disappear from the printed receipt. Test plan: 1. Disable browser popups (Chrome: "Don't allow sites to send pop-ups or use redirects"). 2. Enable FinePaymentAutoPopup. 3. Complete a POS sale. 4. On the receipt page, choose Print to PDF (or trigger auto-print). 5. Verify the printed/PDF output contains only the receipt body — no Print receipt or Close buttons. 6. Verify the buttons remain visible on screen. Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|Small patch |String patch CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.11.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #14 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 on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com Keywords| |additional_work_needed --- Comment #15 from Jonathan Druart <jonathan.druart@gmail.com> --- 01:35:01 # Failed test 'koha-tmpl/intranet-tmpl/prog/en/modules/pos/pay.tt has 'kohaTable' instances in a <script> tag with Template::Toolkit tags.' 01:35:01 # at xt/tt_kohaTable_tidy.t line 58. 01:35:01 # got: '1' 01:35:01 # expected: '0' 01:35:01 # Looks like you failed 1 test of 884. -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Passed QA -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 199950 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199950&action=edit Bug 41705: (follow-up) Fix for new kohaTable requiremens This bug sat in the queue too long and thus there's coding standard changes to resolve. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199950|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 199952 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199952&action=edit Bug 41705: (follow-up) Fix for new kohaTable requirements This bug sat in the queue too long and thus there's coding standard changes to resolve. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main --- Comment #18 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Follow-up pushed to fix tests on main -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Pushed to stable Version(s)|26.11.00 |26.11.00,26.05.01 released in| | --- Comment #19 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Pushed to 26.05.x for 26.05.01 -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.11.00,26.05.01 |26.11.00,26.05.01,25.11.05 released in| | CC| |baptiste.wojtkowski@biblibr | |e.com --- Comment #20 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Pushed into 25.11.x for 25.11.05 nice work everyone -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.11.00,26.05.01,25.11.05 |26.11.00,26.05.01,25.11.06 released in| | --- Comment #21 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- EDIT: pushed to 25.11.06 -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org