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

[Bug 43700] New: Use background report jobs to schedule reports using the task scheduler
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43700 Bug ID: 43700 Summary: Use background report jobs to schedule reports using the task scheduler Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- We could replace the need for the "at" command entirely if we utilize the reports background jobs. Reports would need a "don't run before" datetime column and then the query that fetches the jobs could filter out anything where that column is in the future. The form data would need stored somewhere as well so the output can be emailed properly. A possible further enhancement ( likely a report in it's own right ) would be to add periodicity by having periodic reports stored in a table, and a nightly cronjob that would queue up report background jobs for the next 24 hours based on the periodicity! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43374] New: Allow configuration of bibliographic information to be shown on new record duplicate check - Advanced Editor
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43374 Bug ID: 43374 Summary: Allow configuration of bibliographic information to be shown on new record duplicate check - Advanced Editor Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Bug 41902 - Allow configuration of bibliographic information to be shown on new record duplicate check introduced a way to display more bibliographic information when Koha suspects a newly-created bibliographic record may be a duplicate of an existing record on the basic editor. It would be helpful to see this in the advanced editor too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43576] New: Add icon-only collapsed mode to staff interface sidebar menus
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43576 Bug ID: 43576 Summary: Add icon-only collapsed mode to staff interface sidebar menus Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- This patch enhances the sidebar collapse feature added in bug 42322. Currently, collapsing the sidebar hides all menu links, leaving only the toggle button. This wastes the remaining horizontal space and removes quick access to the menu's options entirely. This patch: - Moves the collapse toggle button inside the grey sidebar background, so it visually reads as part of the menu it controls, rather than a separate floating button. - Introduces an opt-in icon-collapse mode: once a sidebar menu is enhanced with icons, collapsing it shows a narrow icon-only rail (with hover tooltips and the current page still highlighted) instead of hiding everything. - Persists the collapsed/expanded state across page loads using localStorage. - Converts the following sidebar menus to icon-collapse mode: Circulation (patron-context menu and module nav), Cataloguing, Tools, System preferences, Reports, Bibliographic record view, Serials, Labels, Point of sale, Guided reports view, and the Vue-driven Vendor, Acquisitions and Administration menus. Menus not yet converted (facets/tags/search-filter sidebars, and the ERM/ILL/Preservation/SIP2 Vue module navigation) keep today's collapse-to-blank behaviour and can be converted in follow-up patches using the same pattern. Test plan: 1. Apply the patch and rebuild the staff interface assets (yarn build). 2. Log in to the staff interface and go to a patron's detail page (Patrons > search a patron > Details). 3. Confirm the toggle button now sits flush inside the grey sidebar background rather than floating as a separate bordered button. 4. Click the toggle to collapse the sidebar. Confirm the circulation patron menu collapses to a narrow icon-only rail, each icon shows a tooltip on hover, and the current page's icon is still highlighted. 5. Reload the page. Confirm the sidebar remains collapsed (state is remembered across page loads). 6. Expand the sidebar again and visit a page using a menu that has NOT been converted yet (e.g. a facets/filter sidebar). Collapse it and confirm it still collapses to a blank rail as before (no regression). 7. Repeat steps 2-5 for a sample of the converted menus: Cataloguing (e.g. Inventory), Tools, Administration > System preferences, Reports, a bibliographic record's Detail page, Serials, Label creator, Point of sale, Guided reports. 8. Repeat for the Vue-driven menus: Acquisitions home, a vendor's detail page, and Administration (e.g. Authorized values). Confirm icons show, collapse works, and the active page is still highlighted when collapsed. 9. Run the Sidebar_spec.ts Cypress test and confirm it still passes. 10. Sign off. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 82

[Bug 42748] New: Rewrite selenium/administration_tasks.t using Cypress
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42748 Bug ID: 42748 Summary: Rewrite selenium/administration_tasks.t using Cypress Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 29285 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 [Bug 29285] [OMNIBUS] Rewrite Selenium tests using Cypress -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43523] New: cleanborrowers.pl is slow
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43523 Bug ID: 43523 Summary: cleanborrowers.pl is slow Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I have been looking at cleanborrowers.pl and find that it can be slow when dealing with many borrowers. I have identified some areas where I think improvements can be easily made. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43460] New: REST API XML payload conversion breaks plugin API routes that consume XML
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43460 Bug ID: 43460 Summary: REST API XML payload conversion breaks plugin API routes that consume XML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Bug 37762 makes the REST API convert request bodies sent with an application/xml content type to JSON so they can be validated against Koha's swagger definitions, and convert response bodies with an application/xml content type from JSON to XML. Both hooks apply to every route, including the /contrib plugin routes. Plugins define their own API contracts and may read and output XML directly. For example, the POC for the NCIP server plugin accepts XML messages on its route. On Koha 26.05 and later the request hook replaces the incoming NCIP message with a JSON rendering of it before the plugin controller runs, destroying the message such that element attributes and ordering are lost with no way to get to that data. The response hook then dies trying to parse the plugin's XML response as JSON, turning it into a 500. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 43234] New: Move ILL request purging logic to Koha::ILL::Requests
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43234 Bug ID: 43234 Summary: Move ILL request purging logic to Koha::ILL::Requests Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 28740 Target Milestone: --- Follow-up from Bug 28740. Bug 28740 added ILL request purging to cleanup_database.pl using raw SQL in a PurgeIllRequests subroutine. This should be moved to a proper method on the Koha::ILL::Requests collection class. Proposed approach: - Add a filter method (e.g. filter_by_purgeable) that returns a filtered resultset - The script then calls ->count for dry-run or ->delete for actual purge - This follows the pattern used by other Koha::Objects subclasses Example usage in cleanup_database.pl: my $to_purge = Koha::ILL::Requests->filter_by_purgeable( { days => $days, statuses => \\@statuses } ); say sprintf('%d ILL requests would be removed', $to_purge->count) unless $confirm; $to_purge->delete if $confirm; Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 [Bug 28740] Delete old ILL requests with cleanup_database -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 39419] New: Holds API treats 'expiration_date' as 'patron_expiration_date'
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39419 Bug ID: 39419 Summary: Holds API treats 'expiration_date' as 'patron_expiration_date' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is going to have a related issue in Aspen, but I think the confusion starts here Koha has two fields for hold expiration: expirationdate - (usually) auto generated date set based no when holds on the shelf expire patron_exiration_date - the day the patron says they don't need the hold after The API takes "expiration_date" and maps it to "patron_expiration_date" This can be unclear for outside systems. Aspen has a 'Default Not Needed After Days' setting which is assumed to be setting the automatic expiraton date, but in fact sets the patron date We should allow either field to be set via the API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 108

[Bug 43793] New: 26.05.04 backport of bug 42605 is incomplete
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43793 Bug ID: 43793 Summary: 26.05.04 backport of bug 42605 is incomplete Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This is a follow-up to bug 42605: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 The fix released in Koha 26.05.04 only corrects AcqCreateItem. UniqueItemFields is still converted to the numeric value 0/1, so the acquisition receiving dialog remains broken when items are created on receipt. Tested package ============== koha-common 26.05.04-1 Steps to reproduce ================== 1. Set AcqCreateItem to "receiving an order". 2. Set UniqueItemFields to a non-empty value, for example "barcode|stocknumber". 3. Create an order and open it for receipt. 4. Observe that the receiving dialog remains on its loading indicator and the item-entry form is not displayed. Actual result ============= The English template shipped with 26.05.04 contains: Koha.addPrefs({ AcqCreateItem: "[% Koha.Preference('AcqCreateItem') | html %]", UniqueItemFields: [% Koha.Preference('UniqueItemFields') ? 1 : 0 | html %], }); JavaScript therefore receives the number 1 and additem.js fails when it calls: unique_item_fields.split("|") Expected result =============== Both preferences must remain strings: Koha.addPrefs({ AcqCreateItem: "[% Koha.Preference('AcqCreateItem') | html %]", UniqueItemFields: "[% Koha.Preference('UniqueItemFields') || '' | html %]", }); Cause ===== On main, commit 35b58d65c5 from bug 43211 had already corrected UniqueItemFields before bug 42605 commit 757b347bed was applied. The latter therefore only changes AcqCreateItem in its final diff. The 26.05.04 backport appears to include 757b347bed without the relevant change from 35b58d65c5. This makes the stable backport incomplete even though bug 42605 is listed as fixed in 26.05.04. The same incorrect expression is present in the packaged English and de-DE templates. Applying the expected line locally and restarting Plack restores the item-entry form. Please backport the missing UniqueItemFields change to 26.05.x and include it in the next maintenance release. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2