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

[Bug 42610] New: Modification history and restore modifications
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42610 Bug ID: 42610 Summary: Modification history and restore modifications Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.mathevet(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Added a new page that displays a record’s modification history, with the ability to restore previous states. Test Plan: - Go to a record page - Edit the record (modify, add, or remove fields) - Open “Modification history” from the left navigation bar - Select a state to restore - Verify that the restore preview displays the current record and the changes that will be applied - Click “Restore” - Verify that all modified and unmodified fields are correctly preserved in the record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42563] New: Add Koha::Biblio->host_items using MetadataExtractor
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42563 Bug ID: 42563 Summary: Add Koha::Biblio->host_items using MetadataExtractor 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 Currently, C4::Items::get_hostitemnumbers_of is the only way to get items linked via MARC 773$9 (MARC21) / 461$9 (UNIMARC) host record fields. This function lives in the C4:: namespace and mixes MARC parsing with DB queries. This bug adds: 1. get_host_itemnumbers method to Koha::Biblio::Metadata::Extractor::MARC::MARC21 and ::UNIMARC â extracts itemnumbers from the appropriate MARC field 2. Koha::Biblio->host_items â convenience method returning a Koha::Items resultset (gated behind EasyAnalyticalRecords syspref) Replaces C4::Items::get_hostitemnumbers_of using the MetadataExtractor pattern from Bug 34828. Callers to migrate: - Koha::Biblio::Availability::Hold (Bug 42386) - C4::ILSDI::Services::HoldTitle - reserve/request.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 41566] New: Tidy kohaTable block - catalogue
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41566 Bug ID: 41566 Summary: Tidy kohaTable block - catalogue Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 41572] New: Tidy kohaTable block - members
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41572 Bug ID: 41572 Summary: Tidy kohaTable block - members Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 41560] New: Useless (and confusing) id attribute on a couple of script tag
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41560 Bug ID: 41560 Summary: Useless (and confusing) id attribute on a couple of script tag Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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 koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/issuehistory.tt koha-tmpl/intranet-tmpl/prog/en/modules/members/readingrec.tt have <script id="js"> That's not needed, useless, and confusing. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 42591] New: current_item_level_holds+count is not sortable on the API
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42591 Bug ID: 42591 Summary: current_item_level_holds+count is not sortable on the API 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 Depends on: 41950 The current_item_level_holds+count embed on the acquisitions orders endpoint cannot be sorted because the underlying query is too complex for a single DBIC relationship. Koha::Acquisition::Order->current_item_level_holds requires: 1. Getting item numbers from aqorders_items for the order 2. Getting the biblio for the order 3. Querying holds on that biblio filtered by reservedate <= NOW() + ConfirmFutureHolds AND itemnumber IN (those items) This involves a syspref-dependent date calculation and a multi-table correlation that cannot be expressed as a DBIC relationship coderef. A possible approach would be a raw SQL subquery override mechanism in _build_count_subquery, or accepting that this embed remains display-only (not sortable). Test plan: prove t/db_dependent/api/v1/acquisitions_orders.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42588] New: biblio.uncancelled_orders+count is not sortable on the API
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42588 Bug ID: 42588 Summary: biblio.uncancelled_orders+count is not sortable on the API 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 Depends on: 41950 The biblio.uncancelled_orders+count embed on the acquisitions orders endpoint cannot be sorted because the uncancelled_orders DBIC relationship does not exist on the Biblio result class. The Koha::Biblio->uncancelled_orders method currently calls self->orders->filter_out_cancelled which filters on datecancellationprinted => undef in Perl. To make it sortable, we need: 1. A DBIC coderef relationship on Biblio that filters aqorders.datecancellationprinted IS NULL 2. Support for undef values (IS NULL) in _build_count_subquery 3. Update Koha::Biblio->uncancelled_orders to delegate to the DBIC relationship 4. Unit tests proving the sort works The generated subquery would be: (SELECT COUNT(*) FROM aqorders WHERE aqorders.biblionumber = me.biblionumber AND aqorders.datecancellationprinted IS NULL) Test plan: prove t/Koha/REST/Plugin/Query.t t/db_dependent/api/v1/acquisitions_orders.t t/db_dependent/Koha/Biblio.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41685] New: MARC21: Sort 4xx/5xx in BuildSummary alphabetic within hierarchy ($w: g or h)
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41685 Bug ID: 41685 Summary: MARC21: Sort 4xx/5xx in BuildSummary alphabetic within hierarchy ($w: g or h) 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Currently, the list of seefrom/seealso is sorted in the order of the MARC fields. We would like to sort the Broader terms first and the Narrower terms last, with other terms in the middle. All groups should be sorted alphabetically on $a. This summary is mainly used in the authority search results on OPAC and intranet. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 41471] New: Deprecate IndependentBranches system preference in favor of library group enhancements
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41471 Bug ID: 41471 Summary: Deprecate IndependentBranches system preference in favor of library group enhancements Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I suggest to add a deprecation note to the system preference and maybe a coding guideline as well to start phasing out the IndependentBranches system preference in favor of pushing the development for library groups and related features instead. The IndependentBranches have a lot of known holes and problems, see bug 12599. I think if we can agree to start removing it, we could tackle the features it brings separately and improve them to be better, more flexible and more granular in configuration - not being an all or nothing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 41950] New: Make +count embeds sortable by using SQL-level COUNT subqueries
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Bug ID: 41950 Summary: Make +count embeds sortable by using SQL-level COUNT subqueries 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 Currently, +count embeds (e.g., claims+count, checkouts+count) are computed in Perl via $object->$relation->count during to_api serialization. This means: 1. They cannot be used in _order_by — attempting to sort by a _count field (e.g., _order_by=-me.claims_count) causes a 500 error because DBIC cannot find the column in the database. 2. Each count triggers a separate SQL query per row (N+1 problem). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. For example, claims+count on orders generates: sql (SELECT COUNT(*) FROM aqorders_claims WHERE aqorders_claims.ordernumber = me.ordernumber) AS claims_count The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69