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

[Bug 29281] New: Allow per-user configuration of table settings and default sort orders
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29281 Bug ID: 29281 Summary: Allow per-user configuration of table settings and default sort orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 Different users will have different needs for what's shown in any given table in the staff interface. Table settings only allow things to be shown/hidden systemwide. It'd be great to have a way for individual users to pick their own defaults. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42301] New: updatedatabase fails on mysql when adding a unique key to a text column (introduced by 35380)
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42301 Bug ID: 42301 Summary: updatedatabase fails on mysql when adding a unique key to a text column (introduced by 35380) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com The column 'name' is altered to be unique in bug 38530 When using mariadb this works fine but when using mysql as db engine this error is thrown; ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: BLOB/TEXT column 'name' used in key specification without a key length at /kohadevbox/koha/C4/Installer.pm line 818 to recreate: - run ktd with mysql f.e.: DB_IMAGE=mysql:8.0 ktd --proxy --name mysql8 up -d - enter ktd shell ktd --name mysql8 --shell - checkout a Koha version prior to 35380 - reset_all - checkout main - updatedatabase -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 42318] New: Table record_sources is not populated with data on install
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42318 Bug ID: 42318 Summary: Table record_sources is not populated with data on install Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In bug 35380 the table record_sources gets populated with system defined values as 'bulkmarcimport','intranet' and so on. As this works in updates via a script in db_revs (251200037.pl) these values are not populated on a new installation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 35380] New: PUT /biblios/:biblio_id doesn't respect overlay rules
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35380 Bug ID: 35380 Summary: PUT /biblios/:biblio_id doesn't respect overlay rules Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Based on bug 31801#c5, this endpoint should, at least, respect the any default rule as defined in the MARC overlay rules. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 98

[Bug 41328] New: All KohaTable table broken in Vue components
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41328 Bug ID: 41328 Summary: All KohaTable table broken in Vue components Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38426 See the current cypress failures on Jenkins > JS Warning detected: "[Vue warn]: Unhandled error during execution of mounted hook" "\n" " at <KohaTable" "ref=\"table\"" "url=\"/api/v1/preservation/waiting-list/items\"" "options=" {"embed":"biblio","orderCe Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38426 [Bug 38426] Node.js v18 EOL around 25.05 release time -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 39504] New: Batch record modification 'doesn't exist' condition not checking every matching tag
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39504 Bug ID: 39504 Summary: Batch record modification 'doesn't exist' condition not checking every matching tag Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org I feel like this MARC modification template isn't behaving as I expect it to. I have a biblio record with the following MARC: 700 $a John Smith $e Editor 700 $a Sally Smith I want a template that will add a value in 700$e if 700$e doesn't exist. My MARC modification template action looks like: - Add new field 700$e with value test if 700$e does not exist It doesn't work, probably because the earlier 700 tag does have the $e subfield, so the condition is false and it moves on. I've tried with other variations for the template action, for example - Add new field 700$e with value test2 if 700$e does not match RegEx m/(.*)/ Still doesn't apply, and I think it should be normal to expect that the MARC modification template will look at all 700 tags to apply this action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42391] New: Use DBIx::Class exception_action to translate exceptions at the source
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42391 Bug ID: 42391 Summary: Use DBIx::Class exception_action to translate exceptions at the source 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: 19871 Bug 19871 introduced Koha::Schema::Util::ExceptionTranslator to centralize the translation of DBIx::Class exceptions into Koha exceptions. Currently, each caller (Object::store, Object::delete, Item::add_to_bundle) must explicitly call translate_exception in its catch block. DBIx::Class provides an exception_action hook on the Schema that intercepts every throw_exception call before it becomes a DBIx::Class::Exception. By setting this hook on Koha::Schema, we could translate MySQL errors into Koha exceptions at the source, eliminating the need for catch-block boilerplate in every caller. This would: - Remove the translate_exception catch blocks from Object::store, Object::delete, and Item::add_to_bundle - Make every DBIC operation (including raw resultset calls) automatically produce Koha exceptions without caller intervention - Close the gap where unmatched DBIx::Class::Exception errors could slip through template error handlers (identified during QA of bug 19871) - Refactor ExceptionTranslator to work on plain error strings instead of exception objects (exception_action receives the message before wrapping) The exception_action hook is available in DBIx::Class 0.082844 (shipped with KTD) and has been a core feature since early DBIC versions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19871 [Bug 19871] Use new exceptions Koha::Exceptions::Object::DuplicateID and FKConstraint -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 42679] New: Add GET /patrons/{patron_id}/overdues_count endpoint
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42679 Bug ID: 42679 Summary: Add GET /patrons/{patron_id}/overdues_count endpoint Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Add a new REST API endpoint that returns the count of overdue checkouts for a patron as a plain integer. This endpoint computes the count live from the database (date_due < NOW()) to ensure accuracy, as overdue status is time-based with no discrete event to trigger updates. The primary use case is async loading in the patron search table: the main search results render immediately while overdues are fetched separately per visible page, improving perceived performance. Endpoint: GET /api/v1/patrons/{patron_id}/overdues_count Response: integer (e.g. 3) Permission: borrowers => list_borrowers -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 29168] New: Disable "Request article" links when limit is reached
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Bug ID: 29168 Summary: Disable "Request article" links when limit is reached Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Since bug 27945 we can limit article request per patron's category. However the "request article" links (detail and search views) are still active. We could disable them and add a tooltip. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 42044] New: Automatically update LDR/5 for modified records
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42044 Bug ID: 42044 Summary: Automatically update LDR/5 for modified records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org According to https://loc.gov/marc/bibliographic/bdleader.html, the 5th byte of the leader, Record status, could/should be system generated: "System-Generated Elements - Following Leader elements are usually system generated: [...] 05 Record status" Same for authority records. At present, Koha does not automatically update LDR/5 after a record has been modified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22