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

[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 3492] Move hold fee setting into circulation rules
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 Aude Charillon <aude.charillon(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Documentation| |https://gitlab.com/koha-com submission| |munity/koha-manual/-/merge_ | |requests/1200 Resolution|--- |FIXED --- Comment #82 from Aude Charillon <aude.charillon(a)openfifth.co.uk> --- New settings and system preference added to the Koha Manual. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43040] New: We should check if we need to check previous checkouts before we do so
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43040 Bug ID: 43040 Summary: We should check if we need to check previous checkouts before we do so Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Currently: my $check_previous_checkout = $patron->do_check_for_previous_checkout($item_unblessed); if ( $patron->wants_check_for_previous_checkout($item_object) && $check_previous_checkout ) { So we might do the check and throw it away, seems avoidable -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 43039] New: Biblio level hold follows the last item during move on new biblio
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43039 Bug ID: 43039 Summary: Biblio level hold follows the last item during move on new biblio 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Hello According to the bug 6532 and the "new" 'move items in a batch' feature, I've added the same behavior. When a hold is at biblio level and we attach the last item from it on another biblio, the hold follows the item. But of course stays at biblio level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 42910] New: Restore ability to save state for holdings table
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42910 Bug ID: 42910 Summary: Restore ability to save state for holdings table Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 38482 - Disable save state for items tables removed the ability to save the holding table's state due to conflicts with hidden columns. To make the holdings table behave like others in Koha, it would be useful if the save state feature could be restored in a way that doesn't conflict with automatically-hidden columns (along with adding default sorting to the holdings table per bug 38079). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 13888] 'Lists' permission should allow/disallow using the lists module in staff
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13888 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)gmail.com --- Comment #35 from Jonathan Druart <jonathan.druart(a)gmail.com> --- The following line generates a warning in the log: +$public = ( $query->param('public') == 1 && $allow_create_public_lists == 1 ) ? 1 : 0; [2026/07/09 10:23:26] [WARN] Use of uninitialized value in numeric eq (==) at /kohadevbox/koha/virtualshelves/shelves.pl line 68. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42694] New: Koha produces extra authorities for OCLC fast subject headings
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42694 Bug ID: 42694 Summary: Koha produces extra authorities for OCLC fast subject headings Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cgresser(a)jesuit.org.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This applies to anyone who imports Marc21 records in the English-speaking world, and who might have standard Library of Congress subject headings, as well as OCLC fast subject headings. After more extra, manual work, the result of what I'm talking about looks like this: 650 _ 0 ‡aMiracles.‡9133027 650 _ 7 ‡aMiracles.‡2fast‡0(OCoLC)fst01023535‡9200794 As this is fairly complicated to explain I have created a screencast (apologies for the low level of sound): https://youtu.be/4hZexR4vmjs What Koha did with the imported bibliographic record's lines 650 _ 0 ‡aMiracles. 650 _ 7 ‡aMiracles.‡2fast‡0(OCoLC)fst01023535 650 _ 0 ‡aMiracles. was initially not synched to the existing "Miracles" subject in local authorities and for 650 _ 7 ‡aMiracles.‡2fast‡0(OCoLC)fst01023535 Koha added an additional OCLC fast subject heading for "Miracles". This meant that there was a third entry for "Miracles" in our authorities. As you can see I could in the video, this can be fixed manually, but this should not be solution. Also, I don't think that one should tell Koha cataloguers in the English-speaking world who use Marc21 to not use the OCLC fast subject headings, which would probably solve the problem). For a while, I had suspected that Koha does this, as I have repeatedly fixed the same, duplicate authorities, in the last 6-8 months, since moving to Koha. This is really a serious inefficiency, and could put off any cataloguer from Koha. Maybe currently Koha does not really look at the indicators (second indicator 0 = Library of Congress, second indicator 7 = scheme specified in subfield 2). Maybe that would be a starting point for allowing several entries with the same basic string of of characters, whilst the actual entry is different...? I would be grateful if other Koha cataloguers in the Marc21 / English-speaking world would like into this, and if I'm missing a solution, please let me know. Many thanks for considering this, Clemens -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43038] New: The Patron column in the Overdue List table incorrectly displays the item title along with the patron's name
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '26

09 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43038 Bug ID: 43038 Summary: The Patron column in the Overdue List table incorrectly displays the item title along with the patron's name Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: ddvala9(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In the Circulation module, the Patron column in the Overdue List table incorrectly displays the item title along with the patron's name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0