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

[Bug 42779] New: Editing suggestion Fund defaults to None when field previously set.
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42779 Bug ID: 42779 Summary: Editing suggestion Fund defaults to None when field previously set. Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.sowanick(a)corvallisoregon.gov QA Contact: testopia(a)bugs.koha-community.org When editing an existing suggestion the Fund field defaults to none even if fund was previously set. This can lead to removing fund information from the suggestion if not reset by the Staff Member. Testing 1) create suggestion and set fund. Save and note fund is set in Suggestions list page. 2) edit suggestion. Note fund field is defaulted away from the previously set fund. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 41736] New: Move IntranetNav to HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41736 Bug ID: 41736 Summary: Move IntranetNav to HTML customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice if IntranetNav system preference was moved to HTML customizations. It would allow for example translations to different languages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 42627] New: Printing a range of barcodes should be from and quantity instead of from and to
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42627 Bug ID: 42627 Summary: Printing a range of barcodes should be from and quantity instead of from and to Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When printing a barcode range we should have "From" and "Number of barcodes to print" instead of "From" and "To". This way the user could enter the starting barcode and the number to print from there. This is because, like David says in Bug 41162, calculating the difference between from and to is hard. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162#c1 "Number of barcodes to print" could then have a limit, say 1000 which seems fair, and then we just exit the loop after that number. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[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