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

[Bug 27190] New: Debug REST API tests
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27190 Bug ID: 27190 Summary: Debug REST API tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org It can be tricky to debug REST API tests. You can get a "received 500 when 200 expected", but you don't have the error. There is one manual way to do it: $t->put_ok($url)->status_is(200)->json_is($expected_json)->or( sub { warn $t->tx->res->to_string }); But could we provide a generic way to add a diag in case Test::Mojo fails? -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 40800] New: TransferArrived needlessly triggers alerts in SIP
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40800 Bug ID: 40800 Summary: TransferArrived needlessly triggers alerts in SIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org A SIP check-in incorrectly triggers alerts when receiving items in transit at the destination library due to the NotIssued status combined with the TransferArrived message. When an item in transit is checked in at its destination library via SIP clients (sorters, self-service kiosks), the system generates an alert because it finds both: * NotIssued status (item not checked out to a user), therefore a checkin failure * Transfer receipt message Whilst this combination appropriately provides informational messages in the staff client, it's inappropriate for SIP contexts where automated systems don't require transfer receipt notifications and the alert disrupts workflow. The item status transition works correctly (transit → available), but the SIP response incorrectly signals an alert condition, preventing automated systems like sorters from processing transferred items seamlessly. Expected Behaviour SIP check-in of transit items at destination libraries should complete without alerts, allowing automated systems to process transferred items without manual intervention. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 39936] New: Configure blocks per action and per interface in restriction types
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39936 Bug ID: 39936 Summary: Configure blocks per action and per interface in restriction types 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23681 We should make patron restriction types more configurable. Within each restriction type, one should be able to choose whether to allow or block any of a list of actions from any of a list of interfaces. Actions to allow or block: - checkout - renewal - hold - ILL request - purchase suggestion Interfaces to allow or block each action via: - intranet - koha OPAC - SIP - API Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 [Bug 23681] Make patron restrictions user definable -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41368] New: Tools/ManageMarcImport_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41368 Bug ID: 41368 Summary: Tools/ManageMarcImport_spec.ts is failing Initiative type: --- Sponsorship --- status: Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Continuous Integration Assignee: tomascohen(a)gmail.com Reporter: lucas(a)bywatersolutions.com To recreate: 1. cypress run --spec t/cypress/integration/Tools/ManageMarcImport_spec.ts 2. It fails -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 39650] New: Updating the protected flag is not possible when creating a new patron
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39650 Bug ID: 39650 Summary: Updating the protected flag is not possible when creating a new patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When creating a new patron, it is not possible to update the protected flag even when logged in as a superlibrarian. It is still possible to update this flag when updating an existing patron. This seams liked to bug 36085. The check to set the authorization flag CanUpdateProtectPatron (witch restrict the update to only superlibrarian) is itself in a check for op 'edit_form', 'cud-save' or 'duplicate'. The flag CanUpdateProtectPatron is not passed to the template when creating a new user as the op is 'add_form' even when logged in as a superlibrarian. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 37815] New: Protected flag permissions should be honoured in the REST API
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37815 Bug ID: 37815 Summary: Protected flag permissions should be honoured in the REST API Change sponsored?: --- 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: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com (follow-up from bug 36085) We now restrict access to the protected flag in the GUI. This should also be replicated out to the REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 41649] New: Add support for setting the magnetic media flag for SIP in Koha
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41649 Bug ID: 41649 Summary: Add support for setting the magnetic media flag for SIP in Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Bug 11351 added the ability to select a media type for SIP responses, however it didn't set the related 'magnetic' bit for SIP. We could hard code that based on media type, but it would be cleaner to allow configuration at the item type level. I'll post two patches here.. the first we've been running in production for around a decade and I thought I'd posted it years ago but can't find it.. the second making it more flexible. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 41439] New: Column filtering on the circ rules table
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41439 Bug ID: 41439 Summary: Column filtering on the circ rules table 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Circulation Rules table is obscenely wide at this point. We've tried a number of approaches to a new UI in this area, and so far all have got stuck. I'm proposing a smaller impact resolution of just having a set of column groups for display to allow limiting the width of the table to only those fields of interest at the moment you're working. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 41254] New: The filter for item status in item tables should be improved
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41254 Bug ID: 41254 Summary: The filter for item status in item tables should be improved 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the table of items under a record, the filter on status created by Bug 37334 does not meet all the needs of a library because it groups together many different scenarios (in processing, on order, etc.) under a single status, "Not for loan." It is not possible to use this filter to isolate items on order, which is a frequent use case. I don't know what would be the best way to improve this filter. Perhaps we could add the different specific statuses provided for each value of notforloan<>0, prefixing them with "Not for loan" so that they appear close together - Excluded from loan (being processed) - Excluded from loan (on order) - Excluded from loan (non loanable itemtype) etc. And keep the global "Not for loan" renamed as "Not for loan (all reasons)". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 39128] New: When Modifying a record using a template in cataloguing there is no link back to the modified record
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39128 Bug ID: 39128 Summary: When Modifying a record using a template in cataloguing there is no link back to the modified record Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to reproduce this: - From a catalogue record, go to Edit > Modify using a template - At the batch record modification page select a MARC modification template to apply - Click on Modify selected records - You are taken to the Job enqueued page - There is no way to link back to your modified record from this page For this function where only one record can be modified at a time, the user should be automatically returned to the normal view of the record (there will not usually be any need to see the background jobs pages) or from the Jobs enqueued page there should be a link back to the record. As it stands now you have to either run a new search, use the browser Back button or click through to the background jobs and then pick up the link to the record from there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4