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

[Bug 39773] New: OPAC ILL form does not use client-side form validation for required fields
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39773 Bug ID: 39773 Summary: OPAC ILL form does not use client-side form validation for required fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com We're already using a required parameter. We should make use of it in the HTML and add the 'required' attribute to the HTML inputs. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 2172] Cart attaches an iso2709 file, which confuses 99% of patrons
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2172 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers(a)biblibre.co | |m --- Comment #7 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- (In reply to Katrin Fischer from comment #3) > It turns out the attachement can also create problems if the receiving mail > server is strict about attachements. Indeed, SPAM protection is very strong these days. We should simply remove the attachement. And close this never-ending-story ;) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32630] New: Don't delete ILL requests when patron is deleted
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32630 Bug ID: 32630 Summary: Don't delete ILL requests when patron is deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com There is a FK constraint, that makes it so that when a patron is deleted, the ILL requests linked to the account are deleted as well. This can potentially cause a number of problems: * ILL requests deleted could be pending, in shipment etc. You will have no audit track if there are any problems with transport etc. * You won't be able to do reliable statistics on number of ILL requests etc. especially since adding a request is not even logged. I propose that instead of removing the borrowernumber, we either * leave it * set it to NULL Would love to get some input on this one! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 38928] New: Openurl 'id' or 'rft_id' may contain key information
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38928 Bug ID: 38928 Summary: Openurl 'id' or 'rft_id' may contain key information Change sponsored?: --- 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Currently, the Standard backend is mapping 'id' or 'rft_id' in the openurl to 'doi'. But 'rft_id' may contain 'DOI:12345' where '12345' is the doi value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

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

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #271 from Michaela Sieber <michaela.sieber(a)kit.edu> --- There is a fundamental conceptual error in the migration of the overdue rules with branch code. No default rules must be created here, since there were no default rules in the previous version either. The identification of “common” rules is far too simplistic. Consider the following scenario: Your library has 10 patron categories. Branch Centerville: for 6 of these categories, an overdue rule is configured with delay = 3 and the ODUE letter sent by email. However, for the remaining four categories, no rule is configured at all. In the current version, these four categories therefore do not receive any overdue notices. With the migration, you would now create a default rule that would also apply to these four categories. This is incorrect, because we must not make assumptions or create default rules for other institutions whose specific setup and context we do not know. Our conclusion is that only explicit rules may be migrated. This applies both to rules with a branch code and to those without a branch code. We strongly recommend testing with existing, differing overdue rules. For this purpose, we have created ready-to-use SQL insert statements and would be happy to provide them for testing, so that the various migration scenarios can be tested more easily. This is what we've done for testing with KTD: git checkout main ktd up ktd --shell koha-mysql kohadev SQL-Insert statements for overduerules and overduerules_transport_types : INSERT INTO overduerules (overduerules_id, branchcode, categorycode, delay1, letter1, debarred1, delay2, debarred2, letter2, delay3, letter3, debarred3) VALUES (1, '', 'HB', 2, 'ODUE', 0, 4, 0, 'ODUE', 6, 'ODUE', 0), (2, '', 'B', 1, 'ODUE', 0, 2, 0, 'ODUE', 3, 'ODUE', 1), (3, '', 'K', 3, 'ODUE', 0, 6, 0, 'ODUE', 9, 'ODUE', 1), (4, 'LPL', 'K', 5, 'ODUE', 0, 10, 1, 'ODUE', 0, '', 0), (5, 'LPL', 'ST', 7, 'ODUE', 0, 14, 1, 'ODUE', 0, '', 0), (6, 'LPL', 'YA', 10, 'ODUE', 0, 20, 1, '', 0, '', 0), (7, 'SPL', 'SC', 8, 'DUE', 1, 0, 0, '', 0, '', 0); INSERT INTO overduerules_transport_types (id, letternumber, message_transport_type, overduerules_id) VALUES (1, 1, 'print', 1), (2, 2, 'print', 1), (3, 3, 'print', 1), (4, 1, 'email', 2), (5, 2, 'email', 2), (6, 3, 'email', 2), (7, 3, 'print', 2), (8, 1, 'email', 3), (9, 1, 'print', 3), (10, 2, 'email', 3), (11, 2, 'print', 3), (12, 3, 'print', 3), (13, 1, 'email', 4), (14, 2, 'print', 4), (15, 1, 'email', 5), (16, 2, 'email', 5), (17, 2, 'print', 5), (18, 1, 'email', 6); Now everything is prepared for testing the migration scenario. Check the overduerule in Koha staff interface before you apply the patch! # if branch already exists, delete it : git branch -D bug_10190 git checkout -b bug_10190 origin/main git bz apply 10190 updatedatabase yarn build # copies the Apache-Config files to the correct place sudo perl /kohadevbox/misc4dev/cp_debian_files.pl --instance=kohadev --koha_dir=/kohadevbox/koha --gitify_dir=/kohadevbox/gitify restart_all Check the migrated circulation triggers. -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 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 11 Feb '26

11 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