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

[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 39503] New: Linker should always respect thesaurus with LinkerConsiderThesaurus on
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39503 Bug ID: 39503 Summary: Linker should always respect thesaurus with LinkerConsiderThesaurus on Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: MARC Authority data support Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com With bug 30280 and subsequent patches we attempt to respect the thesaurus indication when linking with LinkerConsiderThesaurus on. However, there are still cases when we link wrong. Example: biblio: 650 _1 $a Philosophy [thesaurus: Library of Congress Children's and Young Adults' Subject Headings] will be linked to an authority 008/11 = a [Library of Congress Subject Headings] 150 __ $a Philosophy if 008/11 = b [Library of Congress Children's and Young Adults' Subject Headings] 150 __ $a Philosophy is missing in the system. This is obviously wrong--we should not link to a authority record belonging to a different thesaurus. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 33277] New: Correctly handle linking subfields with no defined thesaurus
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33277 Bug ID: 33277 Summary: Correctly handle linking subfields with no defined thesaurus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is a follow-up to bug 33159, which is a followup to bug 30280 Currently we are handling all subfield other than 6XX as if they are lcsh - this doesn't work in all scenarios. When a record has 008 character 11 =n - "Not applicable" the match won't go through -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 100

[Bug 41714] New: MARC21 authorities thesaurus link hardcoded
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41714 Bug ID: 41714 Summary: MARC21 authorities thesaurus link hardcoded Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org UNIMARC heading mapping to thesaurus is read from the MARC bibliographic frameworks. On the other hand, MARC21 has them hardcoded in `C4::Heading::MARC21`. This has the side effect of not letting the linker tools honor the linking configuration from the frameworks. For example, if you define your own thesaurus `CEPAL_TOPIC` which you maintain with your own tools/process, and link it to `650$a`, running the linker will still look for `TOPIC_TERM` yielding bad results. We should have an implementation that: * Allows opting in to a UNIMARC-like behavior * Has a fallback mechanism for not-configured mappings so we wouldn't expect behavior change besides the frameworks-defined mappings * It doesn't reinvent the wheel on an old library -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 39721] New: Remove GetSuggestion from C4/Suggestions.pm
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39721 Bug ID: 39721 Summary: Remove GetSuggestion from C4/Suggestions.pm Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23990 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 42757] New: Suggester is not passed by purchase-suggestions.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42757 Bug ID: 42757 Summary: Suggester is not passed by purchase-suggestions.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Like Bug 41997 but for the purchase-suggestions.pl page. To recreate: 1. Find a patron 2. From the patron account click the "Purchase suggestions" button 3. Make a suggestion 4. That suggestion is not associated with the patron from step 1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26