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

[Bug 37228] New: API endpoint to set password for patron requires full borrowers permission, but should only require 'edit_borrowers'
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37228 Bug ID: 37228 Summary: API endpoint to set password for patron requires full borrowers permission, but should only require 'edit_borrowers' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov CC: tomascohen(a)gmail.com On the staff side, a user with only edit_borrowers permission can change the password on a patron account. That should be sufficient for changing the password via API as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42018] New: Inconsistent behavior for null values for fields selected in PatronDuplicateMatchingAddFields
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42018 Bug ID: 42018 Summary: Inconsistent behavior for null values for fields selected in PatronDuplicateMatchingAddFields Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com PatronDuplicateMatchingAddFields behaves differently for null values depending on whether the null values are in the existing patron record or the record being created. To replicate: -Set PatronDuplicateMatchingAddFields to surname, firstname, email Scenario 1: -Create patron A with a first name and surname, but null email -Create patron B with a first name and surname matching patron A, but a value in email -----> NOT FLAGGED as duplicate Scenario 2: -Create patron A with a first name, surname, and email -Create patron B with a first name and surname matching patron A, but null email -----> FLAGGED as duplicate It seems that the two scenarios should behave the same way, or that there should be documentation of the different behavior in the manual. This applies to 40082 but is also true for duplicate matching in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 36724] New: Add cartographic mathematical data to Elasticsearch index mappings
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36724 Bug ID: 36724 Summary: Add cartographic mathematical data to Elasticsearch index mappings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz Search whole 255 field https://www.loc.gov/marc/bibliographic/bd255.html Test with values like * Scale 1:22,000,000 * Conic proj. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 42013] New: Confirmation dialog for "Remove all reserves" never shown on course details page
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42013 Bug ID: 42013 Summary: Confirmation dialog for "Remove all reserves" never shown on course details page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org On the course details page (course_reserves/course-details.tt), clicking "Remove all reserves" skips the confirmation dialog and immediately submits the form. The "Remove all reserves" button (#rm_items_button) is an <a> tag separate from the #rm_items form. The click handler on the button calls $("#rm_items").submit() programmatically. A separate $("#rm_items").click(...) handler was intended to show a confirmDelete dialog, but it is bound as a click event on the form element, which is never clicked by the user. jQuery's .submit() method also does not trigger click events, so the confirmation is never shown. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 40159] New: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40159 Bug ID: 40159 Summary: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce the issue : Make a record and create a subscription for this record with a week or month subscription length and a first issue date in the past (like 2016). Receive at least one issue. Edit the subscription and test the prediction pattern. The displayed prediction shows only one number (unless you set the subscription length for like a thousand issues). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33276] New: Library limitations will cause data loss when editing serials
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33276 Bug ID: 33276 Summary: Library limitations will cause data loss when editing serials Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello @ll, This bug can be related to 31422 and 32748. That's the same behavior on "Locations" dropdown list for serials. When a value is limited to a library if we're logging with a patron from another lib, the location value is empty and can be replaced. I copied the same logic as the submitted patch for 32748. We can modify the value but the current value (provides from another lib) stay in dropdown. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 33738] New: Add bookings to the OPAC
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33738 Bug ID: 33738 Summary: Add bookings to the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 29002 As part of the bookings workflow, we should add support for making bookings from the OPAC as a patron. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are watching all bug changes.

1 61

[Bug 41407] New: OPAC hold history sorts newest to oldest but hides newest to limit to 50
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41407 Bug ID: 41407 Summary: OPAC hold history sorts newest to oldest but hides newest to limit to 50 Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sort of hold history on the opac is unintuitive. It seems like if it's sorting newest to oldest, it should show the 50 newest holds, not active holds then oldest->newest holds until 50. To recreate on main: 1. Allow to override holds in system preferences 2. Allow borrowers to see HoldHistory in the OPAC 3. place at least 51 holds for a single patron. 4. Backdate some of the hold dates to past days, set one of them to be newer than the rest. 5. log in as that patron on the OPAC 6. Go to the holds history 7. observe the 50 holds and see that your newest one doesn't show 8. click the link to view all and see your newst one does show. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 40714] New: cookieConsent: current approach arguable on public computers or shared devices
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40714 Bug ID: 40714 Summary: cookieConsent: current approach arguable on public computers or shared devices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Since we just save a simple key in localStorage, this may still be active on public computers for the next user of that computer? Unless they have separate guest accounts, or cookies and localStorage are cleared when the browser exits. Should we make a difference between browsing anonymous or logging in to Koha within this context of public computers? If so, we might need to save data in the db instead of locally? Looks like this report is less clear than the two others (40712 and 40713). -- You are receiving this mail because: You are watching all bug changes.

1 2