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

[Bug 36561] New: Inappropriate permission for "/api/v1/auth/password/validation"
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36561 Bug ID: 36561 Summary: Inappropriate permission for "/api/v1/auth/password/validation" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Today I was looking to replace a third-party's usage of ILS-DI AuthenticatePatron with the REST API's "/api/v1/auth/password/validation", when I realized that it would mean giving the third-party much greater Koha permission than they currently have. "/api/v1/auth/password/validation" requires the "borrowers" permission, which gives you full access to all borrower data. I don't think that's what we want to give a third-party that really just needs to validate that a patron is an authentic member of Koha. I think that we might need a new permission class. I don't have a perfect name for it yet, but I'm thinking about it. Here's some ideas: - Discovery - External - API - Web services - Third-party -- That way, we can have third-party API users that are narrowly scoped to just what they need to do. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 40996] New: Patron search autocomplete missing from acquisitions homepage search
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40996 Bug ID: 40996 Summary: Patron search autocomplete missing from acquisitions homepage search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If one is searching for orders from acqui/histsearch.pl, the "Basket created by" field will give auto-complete suggestions. The acq homepage has the same search form, but does not suggest patrons for auto-complete. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31344] New: autoBarcode new orders
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31344 Bug ID: 31344 Summary: autoBarcode new orders Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Neither autoBarcode or barcode.pl are creating false barcodes when uploading new/on-order marc records. This is how I think it should work. autoBarcode is set to generate barcode.pl is set in Marc framework for the 952 subfield stage a marc record, ensure the record will add items upload staged marc review items on imported records item barcodes will have autobarcodes and will not be blank -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 41022] New: In holding table limit the values of each filter to values actually present in items
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '25

02 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41022 Bug ID: 41022 Summary: In holding table limit the values of each filter to values actually present in items Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Maybe it is difficult or not possible but it would be nice to limit the values for items filters to the values actually present in items for each specific record. This could be applied to the 4 fields for which a dropdown list is displayed (item type, homebranch, holdingbranch, status) Ex : you have only 2 items, of item type "book" and "map" => the filter should propose only 2 options ("book" and "map") and not the complete list of item type configured in the system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '25

02 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #13 from Mathieu Saby <mathsabypro(a)gmail.com> --- Should we merge this with https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33432 Move a list of items from a record to an other ? My institution could consider funding a development. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 41165] New: In items table use a dropdown menu for filtering on columns controled by an authorized value
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '25

02 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41165 Bug ID: 41165 Summary: In items table use a dropdown menu for filtering on columns controled by an authorized value Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the items table beneath a record it would be nice if we could filter with a dropdown menu if the column (ccode for example) is controled by an authorized value in the framework. Perhaps not everyone will agree, since this would make it impossible to identify abnormal values. Despite that, I think there must be a way to manage this ergonomically. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0