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

[Bug 40949] New: Bookings to collect shouldn't tell staff to check in items
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40949 Bug ID: 40949 Summary: Bookings to collect shouldn't tell staff to check in items Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 33736 On the Bookings to collect page (pendingbookings.pl), under the headers is the text: "The following items have not been collected for bookings. Please retrieve them and check them in." The second sentence does not make sense: checking items is relevant for holds but bookings do not need to be checked in. The second sentence should be removed on this page - or updated to something relevant to bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33736 [Bug 33736] Add bookings to collect circulation report -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41602] New: Cannot combine filters with holds status filters
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41602 Bug ID: 41602 Summary: Cannot combine filters with holds status filters Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Test plan: 1 - Go on http://your_ktd:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=360 2 - Filter by Status: Available 3 - Check any other filter combined with the Status, you get a 500 error -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 42559] New: OpacFavicon double-encodes custom favicon URLs
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42559 Bug ID: 42559 Summary: OpacFavicon double-encodes custom favicon URLs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The OpacFavicon system preference is documented as accepting a complete URL to an image for the OPAC favicon. However, the OPAC template outputs the value using the url filter. If the URL contains an already-encoded character, such as %20 for a space in a filename, the % is encoded again and the rendered URL becomes %2520. This causes the browser to request an invalid favicon URL. The staff interface does not have this issue because IntranetFavicon is output with the html filter instead. The OPAC should handle custom favicon URLs consistently with the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 42920] New: Looking up authority records in Advanced editor appends 20 extra spaces
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42920 Bug ID: 42920 Summary: Looking up authority records in Advanced editor appends 20 extra spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21453 Target Milestone: --- The patch for bug 21453 replaced an Advanced editor-specific (in the "[% IF rancor %]" block) "[%- END -%]‡9[% authid | html %]";" which trims whitespace with several lines of "[% ... %]" which do not trim whitespace. The result is that when you look up an authority from the Advanced editor, you get something like ‡aBildungsromans. ‡9220 with twenty extra spaces before the ‡9. While we could restore trimming the whitespace, that section of the patch wasn't needed, and has made things incorrect for anyone who dares to use the Advanced editor with UNIMARC (probably nobody, since it doesn't do UNIMARC fixed-field builders): since the Advanced editor is only used for biblio records, not authority records, it *should* be putting the authid in ‡9 for both MARC flavors the way it was before, but now it will put it in ‡3, the right field for auth-to-auth linking but the wrong field for biblio-to-auth linking. So the right fix is just to revert the changes to the [% IF rancor %]" block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 [Bug 21453] blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 41977] New: Hold fee not charged for title-level holds when all items have negative notforloan status
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41977 Bug ID: 41977 Summary: Hold fee not charged for title-level holds when all items have negative notforloan status Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When a hold is placed on a title where all items have a negative notforloan value (e.g. -1 = "Ordered" — the Koha convention for "not for loan, but holdable"), no reservation fee is charged, even when the applicable circulation rule specifies a hold_fee. The same hold placed on a title where items have notforloan = 0 (available) correctly generates the charge. Steps to Reproduce 1. Configure a circulation rule with a hold_fee for a patron category and item type (e.g. "Adult Fiction Paperback"). 2. Set HoldFeeMode to any_time_is_placed. 3. Create a biblio with one or more items, all with a negative notforloan value (e.g. -1, "Ordered"). 4. Place a hold on that biblio for a patron in the matching category. 5. Observe the patron's account — no reservation fee is applied. Expected: Reservation fee is charged at hold placement, matching the fee that would apply once the item is received. Actual: No fee is charged. The patron can hold the title free of charge for its entire on-order period, then be charged when it arrives — inconsistent and unfair to patrons who paid for the same hold earlier. Root Cause In Koha/Hold.pm, _calculate_title_hold_fee() searches for items to base the fee on using this filter: -or => [ { 'me.notforloan' => 0 }, { 'me.notforloan' => undef } ] This excludes items with negative notforloan values. When all items on a biblio are in an "Ordered" state (negative notforloan), no items match, @fees is empty, and the method returns 0 — causing charge_hold_fee() to skip the charge entirely. However, Koha's own holdability convention (documented in IsAvailableForItemLevelRequest() and CheckReserves()) explicitly states: "item with negative or zero notforloan value is holdable" (notforloan > 0 blocks holds; notforloan <= 0 allows them) The fee calculation code does not follow this same convention, causing the mismatch. Fix Change the notforloan filter in _calculate_title_hold_fee() (Koha/Hold.pm) from matching only = 0 to matching <= 0: # Before -or => [ { 'me.notforloan' => 0 }, { 'me.notforloan' => undef } ] # After -or => [ { 'me.notforloan' => { '<=', 0 } }, { 'me.notforloan' => undef } ] This aligns fee calculation with the holdability logic used consistently elsewhere in the codebase. Test Plan 1. Apply patch. 2. Configure a hold_fee circulation rule for a patron category and item type. 3. Create a biblio with items having notforloan = -1 (Ordered). 4. Place a title-level hold for a matching patron. 5. Confirm a reservation fee is now added to the patron's account. 6. Confirm that items with notforloan = 1 (positive, truly not holdable) still produce no fee. 7. Run prove t/db_dependent/Koha/Hold.t. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 40817] New: Holds charges should be accessible from Holds
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40817 Bug ID: 40817 Summary: Holds charges should be accessible from Holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 3492 It should be easy to get from a hold to it's associated charges.. i.e. Hold fee, Cancellation fee, any processing fees. This would be useful for API responses and display purposes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 [Bug 3492] Move hold fee setting into circulation rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 40808] New: Holds charges should be accessible from Holds
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40808 Bug ID: 40808 Summary: Holds charges should be accessible from Holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com It should be easy to get from a hold to it's associated charges.. i.e. Hold fee, Cancellation fee, any processing fees. This would be useful for API responses and display purposes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 33501] New: Cashup amount should be configurable
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Bug ID: 33501 Summary: Cashup amount should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems the Cashup summary only accounts for the cash payment type. We have a check payment type that should also be included. Am I missing a configuration somewhere, or do we need some way to define what should be included in the summary and intake balance? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42548] New: Add possibility to list multiple barcodes or one biblionumber on attach item action
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42548 Bug ID: 42548 Summary: Add possibility to list multiple barcodes or one biblionumber on attach item action Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello When you want to attach items on biblio record it will be useful to add a list of barcodes or a biblionumber (if you want to attacn all items in one shot). So this patch will introduce this feature, I will add bug 6532 and 42451 dependants cause I added a method to move all items in a batch and this patch adds refactoring of this to prevent duplicate code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 40445] New: Point of Sale reconciliation input during daily summaries
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40445 Bug ID: 40445 Summary: Point of Sale reconciliation input during daily summaries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk We use a separate spreadsheet for our daily reconciliation of income taken which uses the cash register summaries. It occurs to me that this process can be streamlined by allowing an input stage to the summaries process so staff interaction with summaries is not the cashing up to package the transactions into a summary (we want the daily summaries to happen automatically) we want the staff input to be to add in (against totals for payment type and cash register) the amount of what was actually taken using the z reports and physical cash, i.e. a reconciliation stage so it will be easy for staff to see if the money is 'out' and then a process to reconciliate with a way to add in a note for the summary they are signing off with an perhaps a way for them to then 'balance the books' to account for the discrepancy. We would then need this staff input on the summaries (the physical amount taken and any notes) to be stored in a table, somewhere logical, so we can then report on this and create a way in which library managers can check in on this if needed and audit. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 322