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

[Bug 37477] New: Add option to override warm-up/cool-down periods on bookings at booking time
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37477 Bug ID: 37477 Summary: Add option to override warm-up/cool-down periods on bookings at booking time Change sponsored?: --- 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 34440 We add the option to specify lead and trail times on bookings in bug 34440. It would be a nice addition to add the option for some users to opt to override the rules at booking time in some cases. Example; You add a trial time rule of 3 days which should account for tardy patrons in your organisation returning the items at the end of their booking period. However, you're making a booking for a patron who you trust to return the book on time so you want to, in this case, allow an override to reduce the trail time. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34440 [Bug 34440] Add warm-up and cool-down periods to bookings -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 37618] New: Select patron's, then item's home library by default for pickup location when creating bookings
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37618 Bug ID: 37618 Summary: Select patron's, then item's home library by default for pickup location when creating bookings Change sponsored?: --- 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When working with many bookings per day, always selecting the pickup location can become cumbersome. I'd suggest using the patron's home library as a preselection within the pickup library field in the bookings creation modal and to fall back onto the item's home library if the patron's home library is not available. Would you also consider this a sane default? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 42156] New: Staging and matching authorities with bad characters can fail
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42156 Bug ID: 42156 Summary: Staging and matching authorities with bad characters can fail Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have some protections on bibliographic records with bad characters to avoid dying, however for authorities we don't do the same. Importing records with invalid characters can kill the matching jobs during staging -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 36509] New: Add option to search authority records by ID
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36509 Bug ID: 36509 Summary: Add option to search authority records by ID Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 37449] New: Authority matching using Elasticsearch on 'Number' fields fails
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37449 Bug ID: 37449 Summary: Authority matching using Elasticsearch on 'Number' fields fails Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The query created for authority search always uses `.ci_raw`.. but that doesn't exist for all search field types, including 'Number'. Fridolin added ci_raw for type 'Std Number' in bug 31695 because of this, but I'm not sure that's the right approach globally. We found this when attempting to add a 001 match rule.. local-number defaults to type 'Number' and this never matches anything because 'Number' doesn't include a ci_raw to search against. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #951 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 205322 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=205322&action=e… Bug 10190: (QA follow-up): fix: only remove restrict if no restricting overdues found Where a patron had multiple overdues that ought to cause debarment, it was found that removing one removed the restriction. This is because has_restricting_overdues() was looking up the ItemType object tied to the overdue issue, then passing it down to Koha::CirculationRules->get_effective_rules(). get_effective_rules(), however, expects an itemtype code. This resulted in false negatives: the patron was treated as having no restricting overdues left where they in fact did. Amend this by calling effective_itemtype() instead. Note on side effects: I think this also will activate the previously potentially dead dedup logic in has_restricting_overdues (eq had been used to compare obj instance to obj instance which had no effect (itemtype() runs a find() on each iteration), and is now used to compare itemtype code to itemtype code). Test plan (based on Pedro's comment number 949): 0) Pick a test opac patron, if using Henry from above remove the permissions 1) http://localhost:8081/cgi-bin/koha/admin/categories.pl, edit the test patron's category, confirm 'Overdue notice required' is set to 'Yes'. 2) Set syspref AutoRemoveOverduesRestrictions to when_no_overdue_causing_debarment. 3) http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl, 'Add new trigger'. Leave 'Library' as 'All libraries' and 'Patron category' as 'All categories', set 'Item type' to 'Books'. For 'Letter' pick ODUE, check 'Email' under 'Transport type(s)', set delay to 5 days, for 'Restricts checkouts' select 'Yes', 'Submit'. 4) Check out barcodes 39999000019186 and 39999000007558 to the test patron (confirm both are itemtype 'Books'). Backdate both due dates 6+ days overdue. 5) perl misc/cronjobs/overdue_notices.pl -n — restricts the patron. 6) Check the patron's 'Restrictions' tab: confirm restricted. 7) Return barcode 39999000019186 only, leave 39999000007558 8) Check the patron's 'Restrictions' tab again. Notice they are still restricted (39999000007558 is still overdue). 9) Return barcode 39999000007558 also. 10) Check the patron's 'Restrictions' tab again. Notice the restriction is now removed (a hard refresh may be needed) as no restricting overdues are left. Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #950 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Pedro Amorim (ammopt) from comment #949) > Found a few more issues on a follow up review round: > > Issue #1: Permission migration drops blanket Tools-flag access > > Before applying patches: > 1) Grab 1 patron (using Henry for this example): > 2) Give Henry the 'catalogue' and 'tools' permissions. > 3) Login as Henry, notice you have correct access to Overdue Notice / Status > trigger tool - works fine: > http://localhost:8081/cgi-bin/koha/tools/tools-home.pl > 4) Confirm why. inside ktd: > koha-mysql kohadev -e "SELECT * FROM user_permissions WHERE > borrowernumber=19 AND code='edit_notice_status_triggers';" > 5) Query returns empty. This is because this patron does not have that > specific permission, it has the parent 'tools' permission. > 6) Apply patches, run updatedatabase. > 7) Check what the migration wrote: > koha-mysql kohadev -e "SELECT * FROM user_permissions WHERE > borrowernumber=19 AND code='manage_circ_triggers';" > Expected: a new row. Actual: still empty, nothing carried over, because the > migration only ever reads from user_permissions, and there was never a row > there to read > 8) Login as that patron, notice you can't see the circulation triggers at: > http://localhost:8081/cgi-bin/koha/admin/admin-home.pl > > > Issue #2: itemtype restriction wrongly lifted on return > > 0) Pick a test opac patron, if using Henry from above remove the permissions > 1) http://localhost:8081/cgi-bin/koha/admin/categories.pl, edit the test > patron's category, confirm 'Overdue notice required' is set to 'Yes'. > 2) Set syspref AutoRemoveOverduesRestrictions to > when_no_overdue_causing_debarment. > 3) http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl, 'Add > new trigger'. Leave 'Library' as 'All libraries' and 'Patron category' as > 'All categories', set 'Item type' to 'Books'. For 'Letter' pick ODUE, check > 'Email' under 'Transport type(s)', set delay to 5 days, for 'Restricts > checkouts' select 'Yes', 'Submit'. > 4) Check out barcodes 39999000019186 and 39999000007558 to the test patron > (confirm both are itemtype 'Books'). Backdate both due dates 6+ days overdue. > 5) perl misc/cronjobs/overdue_notices.pl -n — restricts the patron. > 6) Check the patron's 'Restrictions' tab: confirm restricted. > 7) Return barcode 39999000019186 only, leave 39999000007558 > 8) Check the patron's 'Restrictions' tab again. Expected: still restricted > (39999000007558 is still overdue). Actual: restriction is gone. Re- Issue #1: yes, and to my knowledge, that is deliberate. With the migration of the UI and related triggers configuration actions from the 'Tools' section to the 'Administration' section, it was decided not to automatically upgrade staff with tools-level permission only. If memory serves this was discussed over hackfest, and it is where we landed: the reasoning was that it was more detrimental to automatically grant higher permission roles to staff than it is to gate the new UI appropriately, and let libraries choose whether to grant the new permission. But I'll happily stand corrected if I'm misremembering any of that! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36893] New: Shibboleth Login not honouring branch selector
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36893 Bug ID: 36893 Summary: Shibboleth Login not honouring branch selector Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: ryan.henderson(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org A client of ours has recently installed Shibboleth SSO into their staff client. They have asked us to help honour the branch selector on the staff login screen but Shibboleth is ignoring this from what we can see and is only logging staff into their default branches. We think this would be a nice enhancement to the authentication module, to help people login to their requested branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 41264] New: Hold pickup location changes not logged when made from patron record
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41264 Bug ID: 41264 Summary: Hold pickup location changes not logged when made from patron record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com To recreate: - enable Holds Log - place a hold - change its pickup location from the bib record - change its pickup location from /cgi-bin/koha/circ/circulation.pl - change its pickup location from /cgi-bin/koha/members/moremember.pl - search action logs for your hold - confirm only the pickup location change from the bib has been recorded -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 43483] New: Authority linker treats the same name heading differently in 6XX vs 1XX/7XX
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43483 Bug ID: 43483 Summary: Authority linker treats the same name heading differently in 6XX vs 1XX/7XX Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support 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 LinkerConsiderThesaurus is enabled, the authority linker treats a name heading differently depending on whether it appears in a name field (100/110/111/700/710/711 etc, where MARC21's 2nd indicator is undefined) or in the equivalent name-used-as-subject field (600/610/611 etc, where the 2nd indicator encodes the subject thesaurus). C4::Heading::MARC21::parse_heading only computes a 'thesaurus' value for 6XX tags: my $thesaurus = $tag =~ m/6../ ? _get_subject_thesaurus($field) : undef; # We can't know the thesaurus for non-subject fields C4::Heading::_search then only adds a thesaurus constraint to the authority match query when $thesaurus is defined: if ( $check_thesaurus && $thesaurus ) { push @marclist, 'thesaurus'; ... } So the same person can end up matched to, or auto-creating, two separate authority records from the same bibliographic record: one for their 100 field (no thesaurus constraint, matches/creates against auth_type PERSO_NAME alone) and a different one for their 600 field (thesaurus constraint applied, even when indicator 2 is blank, which is treated as the placeholder thesaurus 'notdefined'). The two authority records end up with identical headings, so Koha's own duplicate-authority detection later flags them as duplicates when a cataloguer tries to merge or link them manually, even though the automatic linker created them as two separate records in the first place. This is not a new regression. Bug 33277 (2023) deliberately made thesaurus undef for non-6XX tags, to stop 100/700 fields failing to match authorities that had no thesaurus recorded at all. Its commit message notes the trade-off explicitly: "this means that Koha does not support multiple thesaurus records for authorities outside of subjects." Nobody has revisited the resulting asymmetry between a name field and the same auth_type used as a subject field. This was reported by a customer after bug 31925 made the 6XX-vs-thesaurus distinction more reliable (correctly coding 008/11 for FAST/MeSH/etc on newly created authorities), which appears to have made this pre-existing asymmetry more visible: a blank indicator 2 on a 600 is still treated as thesaurus 'notdefined' and still gets the thesaurus filter applied during matching, unlike the 1XX/7XX occurrence of the exact same name. Test plan: 1. Turn on LinkerConsiderThesaurus, AutoLinkBiblios and AutoCreateAuthorities. 2. Catalogue a bibliographic record with the same personal name in both a 100 (or 700) field and a 600 field, e.g.: 100 1_ $a Goddard, Giles 600 1_ $a Goddard, Giles $x Criticism and interpretation (blank/undefined 2nd indicator on the 600, i.e. no thesaurus recorded) 3. Save the record, with no existing matching authority in the catalogue. 4. Note that two separate authority records are created for "Goddard, Giles" -- one from the 100, one from the 600. 5. Try to manually merge or link the two authorities together in the Authorities module. Observe that Koha's duplicate detection considers them duplicates of each other, confirming they should have matched to a single authority in the first place. Related bugs: Bug 31925 -- AutoCreateAuthorities needs to preserve subject heading thesaurus. This report surfaced during discussion of that fix; it is not a regression caused by it. Bug 33277 -- Do not search using thesaurus when linking non 6XX fields. Introduced the asymmetry described above, as an accepted trade-off at the time. Bug 39503 -- Linker should always respect thesaurus with LinkerConsiderThesaurus on. Related but narrower: only addresses collapsing 008/11='z' plus 040$f within 6XX-to-6XX matching. Bug 41714 -- MARC21 authorities thesaurus link hardcoded. Touches the same C4::Heading::MARC21 code (the tag-to-auth_type table), but only makes that mapping configurable via frameworks; it does not touch the thesaurus computation or filtering discussed here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10