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

[Bug 33092] New: Add ability to search within a list
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 Bug ID: 33092 Summary: Add ability to search within a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be really helpful to be able to search within a list in both the OPAC and the staff interface. For instance, in both the staff interface, if you are viewing a public list with a lot of items on it, you do not have the ability to see if a specific item appears on the list. This is a needed functionality with larger lists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 18062] New: Damaged Status shows unavilable in results
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18062 Bug ID: 18062 Summary: Damaged Status shows unavilable in results Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When performing a search in the OPAC or staff client and the results include an item that is marked "Damaged" the status shows unavailable on the results page. When you view the detailed view of the record, the item appears as available. Although the item can still be checked out, it is confusing for the patron when they see the unavailable status. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 39417] New: Allow for editing/deletion of default SUGGEST_STATUS authorized values
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39417 Bug ID: 39417 Summary: Allow for editing/deletion of default SUGGEST_STATUS authorized values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are libraries who do not use the default SUGGEST_STATUS authorized values for indicating the status of a purchase suggestion in the staff interface/OPAC. For example, libraries would rather use terminology like "Declined" as opposed to "Rejected". While it is possible to add more authorized values to this auth value category, it would be nice if those default values could be Edited or Deleted by staff, if desired. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42652] New: Add per-account option to allow restricted patrons to retain SIP inet access
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42652 Bug ID: 42652 Summary: Add per-account option to allow restricted patrons to retain SIP inet access Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org This patch adds a new per-account SIP2 configuration flag, `patron_restriction_blocks_inet`, that controls whether a patron with an account restriction (debarment) also has their SIP inet profile blocked. Currently, when a patron is restricted in Koha, the SIP inet field (FID_INET_PROFILE) is set to N. This means online services that use SIP for authentication â such as PC booking systems or printing services â also deny access to the restricted patron. Libraries that want to block a patron from borrowing items but still allow them to use digital services have no way to achieve this. With this flag set to 0/false on a SIP2 account, restricted patrons will receive Y for inet access, allowing them to authenticate to online services, while checkout privileges remain blocked as normal. The default (NULL or true) preserves existing behaviour: restrictions block both checkouts and inet access. Test plan: 1. Apply all patches and run the database update. 2. Go to Administration > SIP2 accounts and edit an account. 3. Confirm the new "Restrictions block internet access" toggle is visible. 4. Create a test patron and apply an account restriction to them. 5. With the toggle unset (default), authenticate the patron via SIP and confirm the patron status response shows charge privileges denied AND inet profile N. 6. Set the toggle to false/disabled for the account and re-authenticate. 7. Confirm the patron status response still shows charge privileges denied but inet profile is now Y. 8. Confirm a non-restricted patron is unaffected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 26866] New: Items table on additem should sort by cn_sort
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26866 Bug ID: 26866 Summary: Items table on additem should sort by cn_sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: - create a bib - add three items with source of classification LCC, call numbers: -- JC43 .G6 1890 -- JC330 .F74 2000 -- JC480 .R63 2006 - on additem.pl, sort the items table by "Full call number" - notice items are order incorrectly, going 330, 43, 480 - use a report to pull the cn_sort values for your 3 items, confirm that ordering by cn_sort in your report correctly orders them 43, 330, 480 We should use cn_sort here to get them in the correct order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 38174] New: Self Checkout renders alert for each checkout in session instead of just most recent checkout
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38174 Bug ID: 38174 Summary: Self Checkout renders alert for each checkout in session instead of just most recent checkout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org In self checkout, if a patron scans a stack of books one at a time, an additional blue alert-info box is rendered for each new checkout. When this list becomes long it can push the barcode input down so far that it goes off screen which can be confusing for patrons. When not using batch checkout, self checkout should only render an alert-info box for the most recent scan. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42406] New: Create permission to allow user to delete only their own reports
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42406 Bug ID: 42406 Summary: Create permission to allow user to delete only their own reports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com It would be helpful to have a permission that allows a user to delete reports they've created themselves but not any report created by another user. The existing permission is "delete_reports" That could be renamed "delete_all_reports" and we could add "delete_own_reports." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 38414] New: Can delete reports with only execute_report permission
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38414 Bug ID: 38414 Summary: Can delete reports with only execute_report permission Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There's a "delete" button within the report preview popup that remains exposed and operable for users with only execute_reports permission. This button should be removed unless one has delete_reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40819] New: Guided reports select column should not be initialized as select2
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40819 Bug ID: 40819 Summary: Guided reports select column should not be initialized as select2 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com This is a follow up from bug 37050. To reproduce: 1. Go to Reports > Create guided report 2. Click Next >> 3. Click Next >> 3. Notice the form has been initialized as select2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 37886] New: SQL reports - Multiselect parameters should be optional
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37886 Bug ID: 37886 Summary: SQL reports - Multiselect parameters should be optional Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: blawlor(a)clamsnet.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 37077 When a report is written with multiselect parameters and the the report is run with nothing selected the report results should not be limited. Multiselect reports use the IN() function, so the SQL should be generated with a comma separated list of all of the authorised values. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37077 [Bug 37077] SQL Reports - Picking only one option for each multiple selection results in wrong query -- You are receiving this mail because: You are watching all bug changes.

1 4