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

[Bug 41833] New: Use YML description for syspref's search
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41833 Bug ID: 41833 Summary: Use YML description for syspref's search Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We currently search using the systempreferences.explanation value in DB, which contains non-translatable strings. It would be better to use the translatable descriptions that are in the yml files. Ideally we should search in the translated version and the English one (for people used to search sysprefs by their English descriptions) -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41828] New: New Permission for Deleting Records in Batch Delete if no Items Remain
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41828 Bug ID: 41828 Summary: New Permission for Deleting Records in Batch Delete if no Items Remain Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: acampbell(a)buttecounty.ca.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 39848 fixed the issue where users without edit_catalogue permission can delete the record if no items remain from the batch item deletion. We and some others (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39848#c7) however have need where we do want staff to be able to delete records when no items remain during batch deletion. Can there be a new permission to allow record deletions the record if no items remain from the batch item deletion? Edit_catalog (per manual): importing records through z39.50/SRU, and duplicating records), edit existing bibliographic records, merge existing bibliographic records, and delete bibliographic records New permission (maybe no_items_delete_record?): remove record if no items remain. I also know that a button can appear when manually (not batch) removing items and the last item has appeared -- something like 'No more items remain. Delete Record?'. Maybe we could have that permission turned on with this permission too since it does the same thing as the checkbox when batch deleting. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41746] New: Add a dev script to insert a new syspref
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41746 Bug ID: 41746 Summary: Add a dev script to insert a new syspref Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 41682 To prevent new discrepancies (see bug 41682) we should provide a dev script to insert easily and cleanly a new syspref. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41682 [Bug 41682] Syspref discrepancies between new and upgraded installs -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 41786] New: membership_expiry.pl -renew -active should include patrons 0-MembershipExpiryDaysNotice days before expiration
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41786 Bug ID: 41786 Summary: membership_expiry.pl -renew -active should include patrons 0-MembershipExpiryDaysNotice days before expiration Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz membership_expiry.pl -renew -active should include patrons 0-MembershipExpiryDaysNotice days before expiration, not exactly MembershipExpiryDaysNotice days before expiration. membership_expiry.pl selects patrons who are expiring in exactly n days where n is the value from MembershipExpiryDaysNotice preference. Let's say, 30 as an example. When we have a cronjob with the following flags membership_expiry.pl -c -n -renew 12 -active it would be expected behavior to renew patrons who are about to expire within 30 days and who have been active in the last 12 months, last activity defined by borrowers.lastseen. It is not the case when lastseen is >12 months away at exactly 30 days from expiration, but <12 months <30 days from expiration. This could happen when login is defined as activity, and patron who hasn't been active receives a notification of an expiring account then logins to update their activity. Once the 30-day mark has been passed, such patrons will simply be ignored and they will expire. This can be fixed with the -before flag, but I think it is unexpected behavior. Also you can only hardcode a value to -before, so if you change MembershipExpiryDaysNotice, it will not update the -before value. I think the expected behavior is to renew patrons 0-MembershipExpiryDaysNotice days before expiration. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41821] New: Cataloguing plugin for 007 changes defaults on Save
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41821 Bug ID: 41821 Summary: Cataloguing plugin for 007 changes defaults on Save Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: janet.mcgowan(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Cataloguers have reported a problem with the marc21_field_007.pl plugin changing positional values that have previously been set in the plugin. Example - in a bib record edit mode - 007 set to Material Type Electronic resource - set 007 position 01 to r- Remote - set 007 position 09 File formats to a- One file format - set 007 position 11 Antecedent/Source to c- File reproduced from an electronic resource - set 007 position 13 Reformatting Quality to |-No attempt to code - other positions are set to No attempt to code Save the plugin. Result in the bib record = cr |||---a|c|| Save the bib record Edit the bib record again. The 007 still shows as cr |||---a|c|| but if you edit using the 007 plugin again it changes the values: 10 Quality assurance target has changed to a- Absent 11 Antecedent/Source has changed to a- File reproduced from original 13 Reformatting Quality has changed to a- Access If you don't realise the plugin has changed values and save the record it changes the values cr |||---aaa|a I'm not a cataloguer so am not sure if there are any other fixed field dependencies that might be affecting this, but it looks like the plugin values aren't sticking. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 23524] New: Can modify/delete funds for locked budgets
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23524 Bug ID: 23524 Summary: Can modify/delete funds for locked budgets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org What are the allowed actions for a locked budget? Should it be read only? To recreate: 1 - From acqui home click on a budget 2 - Edit the budget and lock it 3 - on admin/aqbudgets.pl notice all funds have an action button 4 - You cannot add, but the button is not disabled 5 - You can modify 6 - You can delete -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41794] New: Error 500 in http://192.168.1.12:8080/cgi-bin/koha/cataloguing/z3950_search.pl
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41794 Bug ID: 41794 Summary: Error 500 in http://192.168.1.12:8080/cgi-bin/koha/cataloguing/z395 0_search.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: egpetridis(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 192677 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192677&action=e… intranet-access.log When searching z39.50 targets simultaneously, sometimes we get an 500 error. No further information on what target's response makes koha raise the error. What could be done to * make koha report on the targets sucessfully queried, * make koha not stumble when encountering erroneous replies from z39.50 targets * make koha note in the logs the target raising the error. The following logs are not redacted, the search was repeated after clearing logs and doing an init 6, so that logs would be more readable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 41824] New: Add more patron info to Suggested by column on suggestion/suggestion.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41824 Bug ID: 41824 Summary: Add more patron info to Suggested by column on suggestion/suggestion.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be handy if there was a little bit more information in the 'Suggested by' column. ie. phone number/email address ect -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 35683] New: Record Detail View should more accurately display the material type
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35683 Bug ID: 35683 Summary: Record Detail View should more accurately display the material type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The record detail view appears to pull the Material Type display information from the 000 Leader space 6. This needs more consistency and a better reflection of the material type. Some examples: Projected medium = Film Language Material = Text Mixed materials = Mixed Materials Musical Sound Recording = Music Nonmusical Sound Recording = Sound Manuscript language Material = Text Notated Music = Score Some of these make sense, but others could cause confusion. For example the term Film could imply a motion picture or a 35mm film. Perhaps it would be better if the display replicated the text in space 6. It may be difficult to have better precision with the language because of the continual changing of the definitions over time. To further add to the discussion, if more specificity is wanted, then the 007 could also be used as a check for the display. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Failed QA --- Comment #270 from Michaela Sieber <michaela.sieber(a)kit.edu> --- Today testing results: 1.) Still problems with permissions: - permission error 403 with restricted user 192.168.56.1 - - [11/Feb/2026:16:29:39 +0000] "GET /api/v1/app.pl/api/v1/patron_categories?_per_page=-1 HTTP/1.1" 403 - "http://192.168.56.101:8081/cgi-bin/koha/admin/circulation_triggers" 192.168.56.1 - - [11/Feb/2026:16:29:40 +0000] "GET /api/v1/app.pl/api/v1/circulation_rules/config HTTP/1.1" 403 - "http://192.168.56.101:8081/cgi-bin/koha/admin/circulation_triggers" To reproduce : Edit an existing borrower (e.g. Casey King) and give Permissions for staff, reports and manage_circ_rules and edit_notice_status_triggers Login with this user. Verify that you see Circulation Triggers under Administration. Click on Link "Circulation Triggers" , then you see the error above for two seconds before you are redirected to Koha start page. Question : is the permission edit_notice_status_triggers still relevant? It is still under Tools and not under "Manage Koha system settings (Administration panel) (parameters)" 2.) default x-Button in transport types (Modal edit trigger) - for users it seems that only one transport type is possible To reproduce : Edit a trigger and go to the section "Edit notice for trigger x" select a letter, this adds a new line for transport types with the mentioned default x-Button that prevents to add more than one transport type (e.g. Print+email) 3.) Transport type should be required field if letter exists It makes no sense to have a notice without a definition how the notice is sent. The transport type should therefor be a required field @Chloé : I've sent you Screenshots in Mattermost 4.) Migration scenario We found some odd behavior but need more time to document the scenario. TBC -- You are receiving this mail because: You are watching all bug changes.

1 0