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

[Bug 43568] New: Add ability to user a specific SMTP server for Email to SMS feature
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43568 Bug ID: 43568 Summary: Add ability to user a specific SMTP server for Email to SMS feature Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- There are places that offer their own Email to SMS service ( https://www.oplin.ohio.gov/sms is the one I'm aware of ). If a library wants to use such a service right now, it means all email must go through this email service. It would be good and useful to be able to specify a single SMTP server for Email to SMS to use specifically with all other email going through the standard channels. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 21004] New: Use modal to add and edit notes on receiving orders/shipments page
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21004 Bug ID: 21004 Summary: Use modal to add and edit notes on receiving orders/shipments page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org See bug 20969, but for parcel.pl. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43489] New: Thesaurus filtering should be scoped by auth_type, not by MARC21 tag position
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43489 Bug ID: 43489 Summary: Thesaurus filtering should be scoped by auth_type, not by MARC21 tag position 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 Depends on: 43483 Target Milestone: --- Bug 43483 fixed the most common case of this problem (a blank/undefined 2nd indicator on a 6XX field being coerced to the literal thesaurus value 'notdefined'). This bug tracks the more thorough underlying fix. C4::Heading::MARC21::parse_heading decides whether to compute a thesaurus value purely from the MARC tag position: my $thesaurus = $tag =~ m/6../ ? _get_subject_thesaurus($field) : undef; That means any 6XX occurrence of a name heading (100/110/111/130 used as 600/610/611/630) can still get a thesaurus constraint applied during authority matching whenever indicator 2 is explicitly coded (0-7), even after bug 43483's fix for the blank-indicator case. For example: 100 1_ $a Goddard, Giles 600 10 $a Goddard, Giles $x Criticism and interpretation (indicator 2 = 0, i.e. lcsh explicitly coded) will still search/create against a 'lcsh' thesaurus constraint for the 600 occurrence, while the 100 occurrence has no constraint at all. If the authority created via the 100 field was not recorded with an explicit lcsh thesaurus, the two can again end up as separate authority records, same symptom as bug 43483, just via a narrower path. The real distinction is not "is this tag a 6XX" but "does this heading's auth_type represent a controlled vocabulary term, or a named real-world entity". MARC's indicator-2 thesaurus code exists to disambiguate genuinely separate subject vocabularies (LCSH vs MeSH vs Sears etc) that may define overlapping terms. It has no equivalent meaning for personal names, corporate names, meeting names or uniform titles: NACO name authority records are reused identically regardless of whether the name functions as a main entry (1XX), added entry (7XX/8XX) or subject added entry (6XX) in a given bibliographic record. There is exactly one authority record per real-world entity, not one per (entity, thesaurus) pair. Suggested solution: Replace the tag-position check in parse_heading with an auth_type check. Introduce a small table of auth_types for which a thesaurus is a meaningful concept - genuine subject/vocabulary terms: TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM, MED_PERFRM and only call _get_subject_thesaurus for a 6XX field whose auth_type is in that set. Name-entity auth_types - PERSO_NAME, CORPO_NAME, MEETI_NAME, UNIF_TITLE, NAME_EVENT - would then never get a thesaurus constraint, in any tag position, even when indicator 2 is explicitly coded. This is more thorough and correct than the blank-indicator fix in bug 43483 because: 1. It closes the remaining gap: an explicitly coded thesaurus indicator on a name-type 6XX field no longer fragments matching either, not just the blank/undefined case. 2. It matches real cataloguing practice (NACO/LCNAF): the thesaurus concept is a property of subject vocabularies, not of names. Scoping by auth_type encodes that directly instead of relying on tag position as a proxy for it. 3. It is symmetric by construction for every current and future name auth_type, rather than requiring each edge case (blank indicator, explicit indicator, UNIMARC vs MARC21) to be patched individually as it is discovered, which is how bug 33277 and bug 43483 each arose. 4. Genuine subject/vocabulary auth_types (TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM, MED_PERFRM) keep their existing, correct thesaurus-scoped behaviour, so this does not reopen bug 33277 or affect bug 39503's 6XX-to-6XX collapsing logic. C4::Heading::UNIMARC::parse_heading already always returns thesaurus undef, so UNIMARC is unaffected by either bug and needs no change. Test plan: 1. Turn on LinkerConsiderThesaurus, AutoLinkBiblios and AutoCreateAuthorities. 2. Catalogue a bibliographic record with the same personal name in a 100 field and a 600 field where indicator 2 is explicitly coded (e.g. 0 for lcsh), with no existing matching authority. 3. Confirm only one authority record is created and used by both fields, the same as the blank-indicator case fixed by bug 43483. 4. Confirm existing subject heading matching for TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM and MED_PERFRM auth_types is unchanged (t/db_dependent/Heading.t "_search tests"). Related bugs: Bug 43483 -- Authority linker treats the same name heading differently in 6XX vs 1XX/7XX. This bug depends on it and generalises its fix from "blank indicator" to "any indicator, for name-type auth_types". Bug 33277 -- Do not search using thesaurus when linking non 6XX fields. The auth_type-based check keeps this behaviour for name-type auth_types, so this is not reopened. Bug 39503 -- Linker should always respect thesaurus with LinkerConsiderThesaurus on. Addresses 6XX-to-6XX matching for subject/vocabulary auth_types, unaffected by this proposal. Bug 41714 -- MARC21 authorities thesaurus link hardcoded. Makes the tag-to-auth_type table configurable via frameworks; the auth_type-based thesaurus check proposed here would need to read from that configurable mapping rather than the hardcoded one, if 41714 lands first. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43483 [Bug 43483] Authority linker treats the same name heading differently in 6XX vs 1XX/7XX -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43312] New: Migrate opac-user.tt to use api-client.js for article request cancellation
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43312 Bug ID: 43312 Summary: Migrate opac-user.tt to use api-client.js for article request cancellation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34451 Target Milestone: --- opac-user.tt uses raw jQuery.ajax() for DELETE calls to /api/v1/public/patrons/.../article_requests/.... This needs to be migrated to api-client.js for proper CSRF token handling (bug 34451). -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 43311] New: Migrate opac-memberentry.tt to use api-client.js
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43311 Bug ID: 43311 Summary: Migrate opac-memberentry.tt to use api-client.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34451 Target Milestone: --- opac-memberentry.tt uses raw jQuery.ajax() for PUT calls to /api/v1/public/patrons/.../guarantors/can_see_checkouts. This needs to be migrated to api-client.js for proper CSRF token handling (bug 34451). -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 42386] New: Unify hold availability checks into Koha::Availability pattern
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386 Bug ID: 42386 Summary: Unify hold availability checks into Koha::Availability pattern Initiative type: --- Sponsorship --- status: 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41728, 42385 Hold availability is currently split across three different interfaces with different return shapes: - Koha::Patron->can_place_holds â patron eligibility gate Returns Koha::Result::Boolean with messages - C4::Reserves::CanItemBeReserved â item-level hold policy Returns hashref with {status} - C4::Reserves::CanBookBeReserved â biblio-level hold policy Returns hashref with {status} This bug proposes unifying these into the Koha::Availability pattern introduced in bug 41728: - Koha::Patron::Hold::Availability â patron eligibility checks (expired, debt, restricted, card lost, global hold limit) - Koha::Item::Hold::Availability â item-level hold policy checks (hold policy, circ rules, on-shelf holds, pickup location, etc.) Both would return Koha::Availability::Result and support no_short_circuit and overrides, consistent with the checkin availability class. This would also require untangling patron-level checks that leaked into CanItemBeReserved (e.g. maxreserves in certain code paths) and pushing them back to the patron-level orchestrator. Note: This is a significant refactoring effort. CanItemBeReserved has ~15 different checks with complex interactions. A multi-patch approach is recommended. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 [Bug 42385] Extract _GetCircControlBranch into Koha::Policy::Circulation -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 127

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #56 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- I've filed Bug 43567 - Matching rules offered at record import do not enforce record type match -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43567 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #55 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- (In reply to Pedro Amorim (ammopt) from comment #54) > Issue #2: > 1) Go to 'Cataloging' > 'New record' > (http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?frameworkcode=) > fill in field 020 $a with a test ISBN (e.g. 9781234567897) and a title in > 245 $a, then 'Save' > 2) Catalog a second new record, same 'Default framework', same 020 $a ISBN, > 'Save', confirm Koha shows the normal 'Duplicate record suspected' warning, > this is your baseline proving duplicate detection currently works > 3) Go to 'Administration' > 'Record matching rules' > (http://localhost:8081/cgi-bin/koha/admin/matching-rules.pl) click 'New > rule', fill in a 'Rule code' and 'Description', set 'Record type' to > 'Authority record' and 'Threshold' to 100, under 'Match points' set 'Search > index' to Local-Number, 'Score' to 100, 'Tag' to 001, then save > 4) Go to 'Administration' > 'MARC frameworks' > (http://localhost:8081/cgi-bin/koha/admin/biblio_framework.pl) click 'Edit' > on 'Default framework' > 5) In the 'Matching rules used to find duplicates' dropdown, select the > authority rule from step 3, then 'Submit' > 6) Repeat step 1/2 exactly, same ISBN, still 'Default framework', 'Save' > 7) No duplicate warning appears at all this time, even though it's the exact > same ISBN collision as step 2. Nothing in the UI stopped you from picking an > authority rule here, and picking one silently breaks duplicate detection for > that framework instead of using the description-visible 'Matching rules used > to find duplicates' feature correctly No existing code in Koha makes sure one is selecting a biblio matching rule when working with biblio records. Both stage-marc-import.pl and addorderiso2709.pl show a full list of defined matching rules, regardless of record_type. That said, I've mixed feelings about arguing that this code should be allowed to follow our existing poor standard. -- You are receiving this mail because: You are watching all bug changes.

1 0