https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43451 Bug ID: 43451 Summary: Account payment receipt popup can be blocked by popup blockers (needs PRG pattern like Bug 41705) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org Target Milestone: --- When FinePaymentAutoPopup is enabled, members/boraccount.tt, members/pay.tt and members/paycollect.tt all trigger the printed receipt with a plain client-side window.open() call on page load (see boraccount.tt around "if (payment_id && Koha.prefs.FinePaymentAutoPopup)"). In some browsers this is treated as an unsolicited popup and silently blocked, so staff never see the receipt. Bug 41705 hit the exact same problem in the Point of Sale module and fixed it there by moving to a PRG (Post/Redirect/Get) pattern: pos/pay.pl issues a server-side 303 redirect (instead of a client window.open()) and the sale form itself submits with target="_blank" so the new tab is opened as a direct result of the user's click, which browsers do not block. The receipt page (pos/printreceipt.pl / printreceipt.tt) then supports an autoprint=1 param that triggers window.print() on load and closes the tab afterwards. Bug 43402 added a manual "print/email receipt" notification box to the account-payment side for when FinePaymentAutoPopup is off, but deliberately left the FinePaymentAutoPopup=on window.open() path alone, since porting the PRG pattern here is more involved than in POS: - Paying/writing off a charge on the account side can also trigger item renewals (Koha::Account->pay()'s renew_result), and the current window.open flow shows that feedback (plus the refreshed balance) in the SAME tab that triggers the popup. A straight port of POS's approach (whole tab becomes the receipt via a same-tab redirect) would lose that feedback unless the design deliberately drops it, matching how POS has no equivalent confirmation UI once the receipt tab opens. - Alternatively, giving the payment confirmation form(s) in paycollect.tt target="_blank" (as POS does) opens the receipt in a genuinely new tab without popup-blocker risk, but then the ORIGINAL tab needs its own client-side navigation back to boraccount.pl/pay.pl since a single form submission can only target one destination - and that return navigation can't carry payment_id/renew_result forward either, since those are only known after the (separate) submission completes. Either approach involves changes to paycollect.pl (which is the single choke point for individual/selected payments and writeoffs), pay.pl, boraccount.pl, and their templates, and a considered decision on whether renew_result/balance feedback is acceptable to lose (or needs preserving some other way) when FinePaymentAutoPopup is on. Test plan: N/A yet - this bug is filed to capture the problem and prior art (Bug 41705) before a design is chosen. See discussion for the two candidate approaches outlined above. See also: Bug 41705 (PRG pattern for POS), Bug 43402 (print/email button when FinePaymentAutoPopup is off), Bug 43288 (change/change_given param mismatch on these same receipt links). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.