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

[Bug 38921] New: Remove unused href from Cancel hold link
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38921 Bug ID: 38921 Summary: Remove unused href from Cancel hold link Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 34478 We use koha-tmpl/intranet-tmpl/prog/en/includes/holds_table.inc to display the list of existing holds in reserve/request.pl when you are placing a hold. The cancel button-links are JavaScript-only, showing a confirm modal and then POSTing a form from there, since the op is cud-cancel and has to be a POST. But we left behind a pre-CSRF href attribute which is a double false-positive for me, since it has both op=cancel and uses the Template Toolkit html filter rather than the uri filter for things inserted in a URL parameter. You can see that it doesn't do anything by right-clicking and opening it in a new tab - there's no op named cancel, so it just displays the existing holds and lets you add one, repeating the page you opened the link from, only with garbage after the request.pl? in your URL. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 [Bug 34478] Full CSRF protection -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 20965] New: Batch patron anonymization logic is flawed
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20965 Bug ID: 20965 Summary: Batch patron anonymization logic is flawed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There are two issues here: 1) The tool suggests you can limit by library and checkout date but in fact, the library is not the patrons' library but the library the items were issued at. This is not clear from the UI. 2) When it comes to the actual anonymisation, although we've got a filtered list of Patrons by issues before X and at Library, we then delete ALL issues before X by any of the Patrons selected by the previous query, regardless of which library the checkout took place and thus we ignore the selected Library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39856] New: New Option for Default lost item fee refund on return policy: Refund if unpaid and charge new overdue
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39856 Bug ID: 39856 Summary: New Option for Default lost item fee refund on return policy: Refund if unpaid and charge new overdue Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: trevor.diamond(a)mainlib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Default lost item fee refund on return policy has an option to only refund the replacement cost if unpaid, but this does nothing regarding the overdue. Similar to the "always refund" or "never refund" options, there needs to be an option for Refund replacement cost (if unpaid) and charge new overdue In theory there should be a corollary "restore overdue" but this would not be used in our consortium and I don't want this bug to be discarded as "too hard" in case adding that option overcomplicates things. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 37512] New: Add a function to reset login attempts
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37512 Bug ID: 37512 Summary: Add a function to reset login attempts Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a user tries to much login attempts, they are blocked. There are two ways to unlock the user: 1 - Change the database 2 - Reset the password There is currently no option to simply remove the lock for a blocked account. In BZ 25947 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25947) we added a button to reset the password and another to simply reset the loginattempts. This bug has been created to split the two improvements. This bugs containts the improvements related to the button to reset loginattempts -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 39625] New: Interface logs incorrectly to statistics table when renewing
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39625 Bug ID: 39625 Summary: Interface logs incorrectly to statistics table when renewing Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have a problem that interface logs incorrectly to statistics when renewing. It seems to log a random interface (intranet, opac, api, sip). Often renewal which is made in staff interface is logged as done via api. How to recreate: 1. Search for a patron with renewable checkouts 2. Renew one of patron's items by checkin it in Renew column and selecting then Renew selected items 3. Check the statistics table which interface is recorded SELECT * FROM statistics WHERE borrowernumber=xxx AND type='renew' ORDER BY 1 DESC 4. Repeat 2-3 few times I cannot recreate this problem in a sandbox but maybe that is because I'm there alone? We are currently using version 24.05.01 (with newer security updates). We found some bugs related to this one but they all were closed as fixed about two years ago so maybe this is something else? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 36085] New: Protected Status should come with a permission
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36085 Bug ID: 36085 Summary: Protected Status should come with a permission Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the new enhancement, 26170, add protected status to patrons, this allows any patron to be updated/edited to be a 'protected patron'. Staff with 'edit borrowers' permission will be able to update this status. I believe there should be a permission to allow for this field to be updated/edited within Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 40881] New: Table layout overflow on course interface – table extends beyond container
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40881 Bug ID: 40881 Summary: Table layout overflow on course interface – table extends beyond container Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The Course interface (Course Reserves) page shows a layout issue: the results table overflows horizontally and extends beyond its container. Steps to reproduce 1. Log in to the staff interface. 2. Go to Course reserves. 3. Click New course, fill in the required fields, and click Save. 4. Click Add reserves, add items or biblionumbers, click Submit, then click Save to add reserve. 5. Click Cancel to see the Course details Table ---> table extends beyond container -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 40738] New: Loan period by month as well as days and hours
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40738 Bug ID: 40738 Summary: Loan period by month as well as days and hours Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To compliment the bookings module, we would love to see the option for loan periods to include Months as well as Days and Hours. This would help us as we loan out sheet music for a month at a time for which there is a checkout fee. At the moment we are having to use '30 days' but this isn't ideal as our actual procedure is for 1 month at a time, so a bit of a fudge. I suspect other libraries like us will have items they checkout that are loaned in months, not days, so I'm hoping useful for libraries beyond our own. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39880] New: Add shelving location to cn_browser.tt
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39880 Bug ID: 39880 Summary: Add shelving location to cn_browser.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to have a column for shelving location in the cn_browser results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 40602] New: Broken HTML showing in Alert 'subscriptions' tab
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40602 Bug ID: 40602 Summary: Broken HTML showing in Alert 'subscriptions' tab Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In the "Alert subscriptions" tab in the OPAC there is broken HTML showing on the page, maybe from a merge conflict, because it doesn't actually make sense, to display the name in that spot. To test: * Add a serial subscription and set a notification template * Go to the OPAC and subscribe to the email notification for this subscription (you must be logged in to see the button on the subscriptions tab) * Go to the patron account > tab alert subscriptions * Verify in the last column something like this shows: Frau Karin Mustermann"> X Unsubscribe from email alerts The "Frau Karin Mustermann">" should not be there. -- You are receiving this mail because: You are watching all bug changes.

1 33