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

[Bug 40394] New: Coce cover images should be requested in chunks
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '26

11 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40394 Bug ID: 40394 Summary: Coce cover images should be requested in chunks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you choose to display 100 results per page when searching the catalog, the current Coce client implementation will pick all the identifiers, and make an API call to Coce for the 100 ids. This is problematic because: * It can be overwhelming for the Coce server (it will make a thread/worker busy for too long even when another is idle). * It makes the rendering slow or unreliable. We should at least split the ids list into chunks of some fixed (limited) size. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 41664] New: Moving an item from record A to record B should update OAI modification date of record A
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '26

11 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41664 Bug ID: 41664 Summary: Moving an item from record A to record B should update OAI modification date of record A Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Deleting an item from a record updates the modification date of the record's header in OAI-PMH repository. But moving an item from record A to record B does not currently update that date. It should be, as we are resting on that piece of information to pass on the changes to external systems harvesting Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42508] New: Migrate patron search to Elastic
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '26

10 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Bug ID: 42508 Summary: Migrate patron search to Elastic Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, nick(a)bywatersolutions.com The current SQL-based patron search has numerous shortcomings in functionality and performance. We could mitigate these by switching to an Elastic-based model -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 84

[Bug 31430] New: Add column configuration to tables in vendor search
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31430 Bug ID: 31430 Summary: Add column configuration to tables in vendor search 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 It would be nice if we could select which columns to display in the tables shown in vendor search. It might also be nice to have the option to filter and export, but as they would take up some space, it might be discussable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43125] New: Rewrite FixPriority to use a single bulk UPDATE instead of per-hold updates
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43125 Bug ID: 43125 Summary: Rewrite FixPriority to use a single bulk UPDATE instead of per-hold updates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Blocks: 43123 Target Milestone: --- C4::Reserves::FixPriority currently issues one UPDATE reserves SET priority = ? per non-captured hold on a biblio, on every hold create, cancel or fill. A popular title with 50 queued holds generates 50 individual UPDATE statements on every state change. The function carries its own FIXME comment noting it needs to be rewritten. Replace the per-hold UPDATE loop with a single bulk UPDATE (for example using UPDATE ... CASE WHEN reserve_id IN (...) THEN ... END, or an equivalent bulk statement), preserving the existing priority ordering semantics exactly. This bug is independent of the REST API and Vue work and can be delivered on its own. Test plan 1. Run t/db_dependent/Reserves.t and confirm all FixPriority related tests pass unchanged. 2. Add a test with a large number of queued holds (50+) and assert the resulting priority values match the pre-patch behaviour. 3. Confirm the number of UPDATE statements issued no longer scales with the number of queued holds. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43123 [Bug 43123] Hold placement workflow: Vue modernisation (epic) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 40256] New: System defined MANUAL debit type description is hard coded but the description can be changed
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40256 Bug ID: 40256 Summary: System defined MANUAL debit type description is hard coded but the description can be changed Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Admin -> Debit types 2. See MANUAL debit type with the description of 'Manual fee' 3. Click edit and edit the description. 4. Go back to the Debit types admin page. The description still reads "Manual fee" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 36540] New: Consider modernising the checkout page to be an Vue page
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36540 Bug ID: 36540 Summary: Consider modernising the checkout page to be an Vue page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 The checkouts page is a core function of Koha, The controller has grown very complicated and it can suffer from performance challenges that we keep trying to side step wit preferences work arounds. We should consider working to replace the page with a Vue app and use the modern API's that have been developed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 42598] New: Spent totals on acq homepage and funds page should calculate using quantity received
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42598 Bug ID: 42598 Summary: Spent totals on acq homepage and funds page should calculate using quantity received 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The GetBudgetHierarchy sub from C4/Budgets.pm is used to calculate the Spent amount shown on the acq homepage (/cgi-bin/koha/acqui/acqui-home.pl) and the funds page in admin (/cgi-bin/koha/admin/aqbudgets.pl). This sub calculates using aqorders.quantity rather than aqorders.quantityreceived, which is not strictly accurate. It is possible to receive more items than were ordered, in which case quantity will show the number ordered while quantityreceived will show the number actually received (and therefore the number actually paid for). Note that /cgi-bin/koha/acqui/spent.pl does use quantityreceived, which will lead the two given totals to disagree. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43114] New: When printing hold/transfer slips on return.tt print window does not auto close in Firfox
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43114 Bug ID: 43114 Summary: When printing hold/transfer slips on return.tt print window does not auto close in Firfox Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- 0. Use Firefox 1. Place a hold 2. Trigger the hold 3. Print the HOLD_SLIP 4. Notice the print window does not automatically close itself -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 42920] New: Looking up authority records in Advanced editor appends 20 extra spaces
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42920 Bug ID: 42920 Summary: Looking up authority records in Advanced editor appends 20 extra spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21453 Target Milestone: --- The patch for bug 21453 replaced an Advanced editor-specific (in the "[% IF rancor %]" block) "[%- END -%]‡9[% authid | html %]";" which trims whitespace with several lines of "[% ... %]" which do not trim whitespace. The result is that when you look up an authority from the Advanced editor, you get something like ‡aBildungsromans. ‡9220 with twenty extra spaces before the ‡9. While we could restore trimming the whitespace, that section of the patch wasn't needed, and has made things incorrect for anyone who dares to use the Advanced editor with UNIMARC (probably nobody, since it doesn't do UNIMARC fixed-field builders): since the Advanced editor is only used for biblio records, not authority records, it *should* be putting the authid in ‡9 for both MARC flavors the way it was before, but now it will put it in ‡3, the right field for auth-to-auth linking but the wrong field for biblio-to-auth linking. So the right fix is just to revert the changes to the [% IF rancor %]" block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 [Bug 21453] blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19