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

[Bug 42665] New: Patron expiration date for hold should be mutable from staff interface
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42665 Bug ID: 42665 Summary: Patron expiration date for hold should be mutable from staff interface 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Currently when hold is created columns expirationdate and patron_expiration_date receive a same date value. After creating the hold the value in column patron_expiration_date is immutable both in OPAC and staff interface. It's also not displayed in neither of the interfaces unlike value in expirationdate column. Changing expiration date from staff interface only affects to the expirationdate column giving staff and patrons impression that this is the date when the hold will expire. However holds expire when date in patron_expiration_date is hit. This can be very confusing for staff and customers especially if patron_expiration_date is earlier than the expirationdate. To reproduce: 1. Create a hold for patron and set expiration date for it. 2. Find the hold from your database SELECT * from reserves where borrowernumber = [borrowernumber]. => Take a note of the values in expirationdate and patron_expiration_date columns, there should be same value in both of them. 3. Change holds expiration date from biblios Holds page. 4. Query your database again. => Note that only expirationdate value was changed. 5. Check expiration date value from biblios Hold page and patron Hold tab in staff interface and OPAC. => All have same expiration date as in expirationdate column. I suggest that we: 1. Display patron_expiration_date in biblios Hold page. 2. Display patron_expiration_date in patrons Hold tab in staff interface. 3. Display patron_expiration_date in patrons Hold tab in OPAC. 4. Create a new permission which allows staff to change patron_expiration_date in biblios Hold page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 36346] New: CheckReserves sometimes lead to bad behavior
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36346 Bug ID: 36346 Summary: CheckReserves sometimes lead to bad behavior Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi @ll, Some options in the circulation rules may lead to incorrect returns from CheckReserves. When you enabled AllowHoldPolicyOverride, you can forcing a hold, even when it is not authorized in the "Default holds policy by item type" rule table. Let me explain: when a hold is forced on an item whose itemtype has a holdallowed rule set to "not_allowed", if you return the item, the hold will not be detected. Similarly, when you perform a checkout, the pop-up indicating that a hold has been placed is not displayed. It's possible that in other places in the code this would cause other inconveniences, but I haven't counted them all. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37172] New: HoldItem and HoldTitle do not check all the values of "hold_fulfillment_policy" rule
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37172 Bug ID: 37172 Summary: HoldItem and HoldTitle do not check all the values of "hold_fulfillment_policy" rule Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org values "homebranch" and "holdingbranch" are not checked, leading to forbidden holds to be put from the ILS-DI interface. I think the controls on "hold_fulfillment_policy" should be done in "CanItemBeReserved" rather than "CheckReserves". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 38475] New: InfiniteScrollSelect_spec.ts is failing again
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38475 Bug ID: 38475 Summary: InfiniteScrollSelect_spec.ts is failing again Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 37620 Always the same trouble makers: 19:05:26 koha_1 | 19:05:26 koha_1 | Running: InfiniteScrollSelect_spec.ts (2 of 18) 19:05:26 koha_1 | <?xml version="1.0" encoding="UTF-8"?> 19:05:26 koha_1 | <testsuites name="Mocha Tests" time="28.823" tests="4" failures="1"> 19:05:26 koha_1 | <testsuite name="Root Suite" timestamp="2024-11-15T18:04:50" tests="0" file="t/cypress/integration/InfiniteScrollSelect_spec.ts" time="0.000" failures="0"> 19:05:26 koha_1 | </testsuite> 19:05:26 koha_1 | <testsuite name="Infinite scroll" timestamp="2024-11-15T18:04:50" tests="4" time="28.798" failures="1"> 19:05:26 koha_1 | <testcase name="Infinite scroll Should load the next page on scroll" time="6.060" classname="Should load the next page on scroll"> 19:05:26 koha_1 | </testcase> 19:05:26 koha_1 | <testcase name="Infinite scroll Should correctly submit the form" time="4.674" classname="Should correctly submit the form"> 19:05:26 koha_1 | </testcase> 19:05:26 koha_1 | <testcase name="Infinite scroll Should correctly display labels" time="0.000" classname="Should correctly display labels"> 19:05:26 koha_1 | <failure message="Timed out retrying after 10000ms: `cy.wait()` timed out waiting `10000ms` for the 1st request to the route: `finalPage`. No request ever occurred. 19:05:26 koha_1 | 19:05:26 koha_1 | https://on.cypress.io/wait" type="CypressError"><![CDATA[CypressError: Timed out retrying after 10000ms: `cy.wait()` timed out waiting `10000ms` for the 1st request to the route: `finalPage`. No request ever occurred. 19:05:26 koha_1 | 19:05:26 koha_1 | https://on.cypress.io/wait 19:05:26 koha_1 | at cypressErr (http://localhost:8081/__cypress/runner/cypress_runner.js:75187:18) 19:05:26 koha_1 | at Object.errByPath (http://localhost:8081/__cypress/runner/cypress_runner.js:75242:10) 19:05:26 koha_1 | at checkForXhr (http://localhost:8081/__cypress/runner/cypress_runner.js:134821:84) 19:05:26 koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:134844:28) 19:05:26 koha_1 | at tryCatcher (http://localhost:8081/__cypress/runner/cypress_runner.js:1807:23) 19:05:26 koha_1 | at Promise.attempt.Promise.try (http://localhost:8081/__cypress/runner/cypress_runner.js:4315:29) 19:05:26 koha_1 | at whenStable (http://localhost:8081/__cypress/runner/cypress_runner.js:143192:68) 19:05:26 koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:143133:14) 19:05:26 koha_1 | at tryCatcher (http://localhost:8081/__cypress/runner/cypress_runner.js:1807:23) 19:05:26 koha_1 | at Promise._settlePromiseFromHandler (http://localhost:8081/__cypress/runner/cypress_runner.js:1519:31) 19:05:26 koha_1 | at Promise._settlePromise (http://localhost:8081/__cypress/runner/cypress_runner.js:1576:18) 19:05:26 koha_1 | at Promise._settlePromise0 (http://localhost:8081/__cypress/runner/cypress_runner.js:1621:10) 19:05:26 koha_1 | at Promise._settlePromises (http://localhost:8081/__cypress/runner/cypress_runner.js:1701:18) 19:05:26 koha_1 | at Promise._fulfill (http://localhost:8081/__cypress/runner/cypress_runner.js:1645:18) 19:05:26 koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:5450:46) 19:05:26 koha_1 | From Your Spec Code: 19:05:26 koha_1 | at Context.eval (webpack://koha/./t/cypress/integration/InfiniteScrollSelect_spec.ts:232:11)]]></failure> 19:05:26 koha_1 | </testcase> 19:05:26 koha_1 | <testcase name="Infinite scroll Should correctly display the label when editing" time="3.887" classname="Should correctly display the label when editing"> 19:05:26 koha_1 | </testcase> 19:05:26 koha_1 | </testsuite> 19:05:26 koha_1 | </testsuites> 19:05:26 koha_1 | 19:05:26 koha_1 | (Results) 19:05:26 koha_1 | 19:05:26 koha_1 | ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ 19:05:26 koha_1 | │ Tests: 4 │ 19:05:26 koha_1 | │ Passing: 3 │ 19:05:26 koha_1 | │ Failing: 1 │ 19:05:26 koha_1 | │ Pending: 0 │ 19:05:26 koha_1 | │ Skipped: 0 │ 19:05:26 koha_1 | │ Screenshots: 0 │ 19:05:26 koha_1 | │ Video: false │ 19:05:26 koha_1 | │ Duration: 28 seconds │ 19:05:26 koha_1 | │ Spec Ran: InfiniteScrollSelect_spec.ts │ 19:05:26 koha_1 | └────────────────────────────────────────────────────────────────────────────────────────────────┘ Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37620 [Bug 37620] Fix randomly failing tests for cypress/integration/InfiniteScrollSelect_spec.ts -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 30095] New: Allow to change "warn when late" setting in subscriptions batch modification tool
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30095 Bug ID: 30095 Summary: Allow to change "warn when late" setting in subscriptions batch modification tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29996 Bug 29996 adds a "warn when late" setting for subscriptions. This bug is for being able to modify this setting in the subscriptions batch modification tool. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29996 [Bug 29996] Show an alert on main page when serial issues are late -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 40700] New: Install by default a SRU server with Elasticsearch Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40700 Bug ID: 40700 Summary: Install by default a SRU server with Elasticsearch Koha 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org SRU is a feature proposed by default by Koha if Zebra is used. With Elasticsearch you need to activate (or rather from a librarian point of view, ask your vendor to activate) it with this procedure (if I understand well) https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server Note that the community manual is not clear on that point Would it be possible to make SRU available by default in every Koha, whether Zebra or Elasticsearch is used? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 40989] New: t/db_dependent/OAI/Server.t fails on Debian 13
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40989 Bug ID: 40989 Summary: t/db_dependent/OAI/Server.t fails on Debian 13 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org 1. KOHA_IMAGE=main-bookworm ktd up 2. prove t/db_dependent/OAI/Server.t 3. pass 4. KOHA_IMAGE=main-trixie ktd up 5. prove t/db_dependent/OAI/Server.t # got : 'http://localhost/' # expect : 'http://localhost' Severity = major because it makes the CI fail and hides issues even if not as much as Bug 40680. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 41077] New: [OMNIBUS] Debian 13 and Perl 5.40 compatibility
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41077 Bug ID: 41077 Summary: [OMNIBUS] Debian 13 and Perl 5.40 compatibility Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 42976] New: InstallPlugins reloads every plugin from disk even when only one is being installed
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42976 Bug ID: 42976 Summary: InstallPlugins reloads every plugin from disk even when only one is being installed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 42430 Target Milestone: --- Bug 42430 made Koha::Plugins->InstallPlugins() force every discovered plugin class to be deleted and re-required from disk on every call, so plugin_methods reflects the .pm file as it currently exists rather than a stale in-memory copy left over in a long-lived Plack worker. That fix is applied unconditionally to every plugin found on disk, even when only one specific plugin is being installed or upgraded (as identified via the existing 'include' parameter). This is safe but wasteful: on an instance with several installed plugins, uploading or reinstalling a single one now forces a full delete-and-recompile of every other installed plugin's .pm file(s) too, not just the one that actually changed. This bug is to scope the forced reload: when the 'include' parameter names specific plugin class(es), only those should be deleted and reloaded from disk. When no include is given (the existing "reinstall everything" protective sweep for plugins removed from disk without using the UI), keep today's behaviour of reloading every plugin. Test plan: 1. Enable plugins and install two or more plugins. 2. Run: perl misc/devel/install_plugins.pl --include <one plugin's class> 3. Confirm only the named plugin's .pm file is reloaded/recompiled, and other installed plugins are left untouched. 4. Run: perl misc/devel/install_plugins.pl (no --include) 5. Confirm all plugins are still reloaded, matching current behaviour. 6. prove -r t/db_dependent/Koha/Plugins/ t/db_dependent/Koha/REST/Plugin/ still passes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42430 [Bug 42430] Fix issue with stale plugin methods after plugin upgrade -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42977] New: Plugin upload does not tell InstallPlugins which plugin was uploaded
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42977 Bug ID: 42977 Summary: Plugin upload does not tell InstallPlugins which plugin was uploaded Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 42976 Target Milestone: --- plugins/plugins-upload.pl calls Koha::Plugins->new->InstallPlugins({ verbose => 0 }) with no 'include' filter after extracting an uploaded plugin archive, so it cannot benefit from the scoping added in Bug 42976 -- every installed plugin still gets deleted and reloaded from disk on every single upload, not just the one that was actually uploaded. This bug is to have plugins-upload.pl determine the plugin class name(s) actually contained in the uploaded archive (e.g. from the list of files Archive::Extract extracted under the plugins directory) and pass them via InstallPlugins({ include => \@classes }), so an upload only forces a reload of the plugin(s) it actually changed. Test plan: 1. Install two or more plugins. 2. Upload a new version of one of them via Tools > Plugins. 3. Confirm only the uploaded plugin's class is deleted and reloaded from disk, not every installed plugin. 4. Confirm the uploaded plugin's updated methods are correctly reflected (per Bug 42430's original test plan: upload a version that renames a method and confirm the new name takes effect without restarting Plack). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42976 [Bug 42976] InstallPlugins reloads every plugin from disk even when only one is being installed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3