- Koha-bugs - lists.koha-community.org

[Bug 43437] New: Barcode range printing fails with 500 error when layout contains bibliographic data
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43437 Bug ID: 43437 Summary: Barcode range printing fails with 500 error when layout contains bibliographic data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To reproduce 1. Go to Tools > Label creator > Manage > Layouts. 2. Create or edit a label layout. 3. Set "Choose layout type" to "Bibliographic data precedes barcode" (BIBBAR). 4. Configure the bibliographic data to include a MARC field, for example 245a. 5. Save the layout. 6. Go to Tools > Label creator > New > Barcode range. 7. Enter the barcode of an existing item in both the "From" and "To" fields. 8. Click "Print range." 9. Select a template and the BIBBAR layout created above. 10. Click "Export." 11. Click "Download as PDF." ==> An Error 500 is returned. The logs contain: Can't call method "field" on an undefined value at C4/Labels/Label.pm line 180. The same barcode range can be exported successfully when using a layout which does not require bibliographic data. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 43402] New: Offer button to print receipt when collecting account payments
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43402 Bug ID: 43402 Summary: Offer button to print receipt when collecting account payments 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(a)lists.koha-community.org Reporter: jheltibridle(a)rcplib.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, when you take a payment on a patron's account, you have the choice to enable a system preference to force receipts or not. If you choose to not force the receipt popup with the system preference, there is no quick method to print the payment receipt. To print the receipt, you have to click to the Transactions tab, find the payment you just took, scroll to the right, and click the receipt button and choose print or email. In the Point of Sale module, when you confirm a payment, two links are provided in the audio-alert-action div. This is on the same screen where the payment was, which makes it easy to choose to print the receipt. I would like to see something similar on the members/pay.pl screen. An additional enhancement would be to give these buttons an id so they can be styled using IntranetUserCSS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 37680] New: inconsistencies with the search results when selecting the "Limit to records with available items" option
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37680 Bug ID: 37680 Summary: inconsistencies with the search results when selecting the "Limit to records with available items" option Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 43451] New: Account payment receipt popup can be blocked by popup blockers (needs PRG pattern like Bug 41705)
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

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(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)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.

1 3

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #22 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- I've just gotten Jonathan's old patches to work with current Koha. Right now they only show the Vendor name in the edit item form, not in the table of items at the top of the Manage Items page. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #21 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Created attachment 204779 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204779&action=e… Bug 8676: Show vendor name in source of acquisition To Test: 1 - Add an order to a basket, creating items when placing the order 2 - receive your order 3 - In the Manage Items screen for your record, confirm Source of Acquisition shows the vendor_id in the item edit form when editing your item 4 - APPLY PATCH, restart_all 5 - reload the Manage Items screen, confirm it now shows the vendor name when editing your item 6 - create a new item, confirm you can still enter a value in Source of Acquisition manually 7 - edit an extant item without a Source of Acquisition value, confirm you can add one manually 8 - Order and receive another item, confirm it shows vendor name when editing -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

1 0

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |andrew(a)bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41705] New: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

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(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: black23(a)gmail.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, lisette(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, maryse.simard(a)inlibro.com, testopia(a)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.

1 51