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

[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

[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

[Bug 41822] New: Add --skip-no-sms parameter to borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41822 Bug ID: 41822 Summary: Add --skip-no-sms parameter to borrowers-force-messaging-defaults.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be great to have a special treatment for patrons without any SMS number to avoid setting SMS message preferences when the patron doesn't have a number. Use case : Already in production, we what to use this script to update/unify messaging preferences. Around half the patrons have an SMS number, all have an email address. We want to be able to set SMS notification for those with an SMS number but not for those without any SMS number. Currently, - if we check the SMS checkbox in the patron category then use the script, it will add SMS for every patron, which is not what we want. - But if we uncheck the SMS checkbox in the patron category, it will be removed for patrons that have an SMS number, which is still not what we want. It would be great to not set the SMS preference if the patron have no SMS number, but still set the email preference for this patron. This behavior could be tied to a parameter given to the script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39579] New: Add Ability to restrict patron date of birth on self registration
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39579 Bug ID: 39579 Summary: Add Ability to restrict patron date of birth on self registration 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: alexander.blanchard(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries are getting dates of birth from the self-registration form that make patrons impossible ages e.g. year of birth 1900. Add a system preference to allow libraries to add a maximum age when patrons self register so that they receive an error message if their date of birth exceeds this age, prompting them to make a correction. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 33204] New: Add the ability to filter on patron library for borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33204 Bug ID: 33204 Summary: Add the ability to filter on patron library for borrowers-force-messaging-defaults.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Like filter on category Bug 19454, it would be helpful to filter on a specified library for misc/maintenance/borrowers-force-messaging-defaults.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19