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

[Bug 31930] New: Ignore whitespace before and after barcodes when adding items to rotating collections
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31930 Bug ID: 31930 Summary: Ignore whitespace before and after barcodes when adding items to rotating collections Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When you add items to a rotating collection by copy and pasting the barcode, there will often be whitespace causing a 'barcode not found' error. We should automatically remove/ignore this leading/trailing whitespace as we do in other forms like the checkout/checkin forms. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 28633] New: Add a preferred_name field and an effective_name method to patrons
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 Bug ID: 28633 Summary: Add a preferred_name field and an effective_name method to patrons 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some institutions store legal names in their directories and for patron imports, but would also like to be able to record 'preferred' names in the patro records. It would be nice to have a field for preferred_name and a method to select the preferred name when it exists, and the firstname when it doesn't Following the item we would suggest 'effective_name' - the additional method can be used in patron-title.inc and in notices to simplify name choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 194

[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 31484] New: Renewals disabled message doesn't display all reasons why something cannot be renewed
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31484 Bug ID: 31484 Summary: Renewals disabled message doesn't display all reasons why something cannot be renewed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are many reasons why the renewals-disabled button might display in the issues table but not all of them will display depending on the circumstance, this can hamper librarians ability to make correct choices. For example: 1. Have an item checkout out what can be renewed at least one time BUT make that item overdue. 2. In the renewal column you'll see "0 Not allowed: overdue". That is good. 3. Have 'AllowRenewalOnHoldOverride' set to 'Don't allow' 4. Place the same item from 1-2 on hold. Make it an item level hold on that specific item. 5. Look at the issues table again, it still says "0 Not allowed: overdue". 6. The message should include some language saying the item can't be renewed becuase it is on hold AND it is overdue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 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