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

[Bug 40691] New: CCODE label not includes in case of 'wrong place' problem (and maybe others cases) into inventory.pl
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40691 Bug ID: 40691 Summary: CCODE label not includes in case of 'wrong place' problem (and maybe others cases) into inventory.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello, Just a quick fix: when you create an inventory of items and some items have “wrong place” problems, if they are associated with a collection code, the table will only display the code and not its label. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 32726] New: Authority search result display and relator terms in 22.05
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32726 Bug ID: 32726 Summary: Authority search result display and relator terms in 22.05 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: marius.mandrescu(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 39646] New: Send overdue notice to guarantor when guarantee has no email
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39646 Bug ID: 39646 Summary: Send overdue notice to guarantor when guarantee has no email Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: william.lavoie(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org If a guarantee does not have an email address registered to their account, then the script overdue_notices.pl doesn't send an email to their guarantors either. Additionally, if an email is sent, the letter should not be printed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 15834] New: Options to supress e-mail generated by AutoEmailOpacUser
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15834 Bug ID: 15834 Summary: Options to supress e-mail generated by AutoEmailOpacUser Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Would love to see a selection when creating a new account to suppress the welcome e-mail generated by AutoEmailOpacUser. Sometimes, like when creating accounts for ILL, you don't want to send the info. It would also be great if there were a preference where you could choose patron groups to not send this e-mail to. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34994] New: Consider translations in updatedatabase
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34994 Bug ID: 34994 Summary: Consider translations in updatedatabase Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr I wanted to open the discussion on this subject. Currently, when we insert things in the database using db_revs or updatedatabase, the strings are inserted in English. For a lot of things, like database structure changes and that type of stuff, it's fine. But for new letters, authorized values or additional content, it inserts in English no matter what the language of the installation is. That means that when we update Koha, we have to go in and translate all of those new things in the interface. We already translate the strings for new Koha installations through the translation of yaml files. I was wondering if it was somehow possible to use the yaml files and their translations to insert the new values? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 36737] New: Use translations in db_rev
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36737 Bug ID: 36737 Summary: Use translations in db_rev Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com When something is inserted in the db through a db_rev, it is inserted in English. For most things, it doesn't really matter. But in the case of authorized values and letters in particular, this is problematic in installations that are not in English. >From what I understand, people who have non-English installations correct these in an ad hoc fashion, sometimes through SQL UPDATE statements and other times manually in the interface. Since all the terms used in db_revs are also included in the installer yaml files, and those are translated, we should find a way to reuse the translations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20170] New: Clicking Reregistration Link Causes Enrollment Periods to Stack
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20170 Bug ID: 20170 Summary: Clicking Reregistration Link Causes Enrollment Periods to Stack Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you renew a patron's registration by using the 'Renew' link that is displayed after the expiration warning on the checkout screen, and you click said link more than once, the dateexpiry gets changed and extended a requisite number of times. In other words, if your enrollment period is two years and you double-click this link, the new expiration date will be end up being four years from today. If you triple click it, it will be 6 years. Quadruple click it for 8 years. (It's not possible to do this using the dropdown renewal option as it produces a dialogue box asking for the user to confirm the registration renewal.) To replicate: 1.) Create or select a patron category that has an enrollment period that is calculated in months (not a fixed date, for this example I use 24 months 2.) Find or create a patron in that category with an expired account 3.) Open this patron's account for checkout and find the warning about the patron's expired account 4.) Double click 'Renew' 5.) When the page reloads confirm that the expiration date is now 48 months from today (rather than the 24 dictated by the category enrollment period) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 25680] New: When adding a new patron and missing to fill a field, on saving, the invalidFocus should show the focused field clearly in view.
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25680 Bug ID: 25680 Summary: When adding a new patron and missing to fill a field, on saving, the invalidFocus should show the focused field clearly in view. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: timothy_alexis.vass(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 105571 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105571&action=e… Expected result: The focused field being clearly in view. Steps to reproduce: login: demo password: demo - http://koha.adminkuhn.ch:8080/cgi-bin/koha/members/memberentry.pl?op=add&ca… - Fill in Surname and Save. Result: Focus is set on input with id="cardnumber". Bug: The object is out of view. Expected result: The focused field being clearly in view. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 40546] New: Add access control layer using RBAC (Role-Based Access Control) + ABAC (Attribute-Based Access Control)
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '26

02 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40546 Bug ID: 40546 Summary: Add access control layer using RBAC (Role-Based Access Control) + ABAC (Attribute-Based Access Control) 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The idea here is that you have roles "LibraryAdmin", "CircDesk", "Cataloguing", etc. We would probably attach the roles to patron categories (ie groups) and patrons. Separately we'd have an attribute-based policy. Typically, you have a "subject" (ie Logged in user), "action" (RunReport), and "object" (Report 42). Sometimes you'll also have a "condition"/"context" (LoggedInBranch CPL). This attribute-based policy could then be assigned to a role or a patron. I expect broad policies would be applied at the role level, and then more specific policies would be applied at the patron level. We might find that we rarely or never use them at the patron-level, but probably good to allow for that level of specificity. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 37346] New: The VirtualShelf object should have an 'owner' accessor to return the related owner Koha::Patron
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '26

02 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37346 Bug ID: 37346 Summary: The VirtualShelf object should have an 'owner' accessor to return the related owner Koha::Patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We should add an 'owner' accessor to Koha::Virtualshelf that returns the Koha::Patron who owns the List. The cleanest approach would be to rename the current 'owner' database field to 'owner_id' and then write the usual Koha::Object relation wrapper into Koha::Virtualshelf. This would improve code consistency and allow for access to the owner directly from the object in notices. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17