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

[Bug 20402] New: Implement OAuth2 authentication for REST API
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20402 Bug ID: 20402 Summary: Implement OAuth2 authentication for REST API Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: REST api Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 94

[Bug 23204] New: Script for exporting Elasticsearch mappings to YAML
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23204 Bug ID: 23204 Summary: Script for exporting Elasticsearch mappings to YAML 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: alex.arnaud(a)biblibre.com Target Milestone: --- Sometimes we need to report librarian's mapping changes in DB to the mappings.yaml. This can be long and tedious. So, here is a script that do the job. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 35138] New: Elastic search - add new facets
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35138 Bug ID: 35138 Summary: Elastic search - add new facets 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: michaela.sieber(a)kit.edu We would like to create a new facet for a 9xx-MARC field As Nick mentioned in Bug 18235, Comment 7: -labels shouldn't be hardcoded - staff should be able to set them -we should add more options to what can be faceted- could be out of control but technically any field should be able to be used -ES has better handling for faceting (can provide subsets of existing/current results and allow to step in/out of facets) Problems / Challenges: 1. Translatability: if staff changes or add new labels, they will not be translated 2. same files for elastic and Zebra -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 74

[Bug 18235] New: Elastic search - Configurable facets
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '26

21 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18235 Bug ID: 18235 Summary: Elastic search - Configurable facets Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 14899, 17169, 18174 >From the Elastic mappings configuration page, the librarians should be able to manage facets (display/hide and order). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14899 [Bug 14899] Mapping configuration page for Elastic search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17169 [Bug 17169] Add facets for ccode to elasticsearch https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18174 [Bug 18174] Add the Koha::Object->update method -- You are receiving this mail because: You are watching all bug changes.

1 137

[Bug 28245] New: Language dropdown in advanced search should be sorted
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28245 Bug ID: 28245 Summary: Language dropdown in advanced search should be sorted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The Language dropdown in the advanced search should be sorted. It should be sorted according to the locale of the user. For instance, sorting by iso 629-2 codes favours English. Take for example "German". The code is "ger" and in English it's "German" but in French it's "Allemand", and in German it's "Deutsch". The alphabetical sort should be done to align with the expectations of the language of the user/interface. I'm not sure what to do about non-alphabetic languages like Chinese that don't do alphabetic sorting... Also, this is neat https://perldoc.perl.org/Unicode::Collate::Locale. A core module which adds support for locales. That said, sort for French is weird. The first is normal sort() and the second is Unicode::Collate::Locale sort. $VAR1 = [ 'a', 'e', 'ç', 'é', 'ï' ]; $VAR1 = [ 'a', 'ç', 'ï', 'é', 'e' ]; -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 29194] New: Patron messaging preferences should be ordered
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29194 Bug ID: 29194 Summary: Patron messaging preferences should be ordered Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 28153 comment 3 suggests the preferences should be ordered Alphabetical could differ in different languages, and I think that would be confusing I would suggest a 'logical' ordering - Holds options together, ILL options together, and item option in process order: Checkout, Predue, Due, Checkin Currently the table is ordered by 'message_attribute_id' and these is not a simple way to sort as desired -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 33495] New: Patron search results can be misleading
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33495 Bug ID: 33495 Summary: Patron search results can be misleading 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If I search for a patron barcode, particularly one that has been deleted, there is a slight chance that this number could be part of another searchable field in the patron record, like a phone number. In that case, the Koha might just go straight into the record without skipping a beat, and staff make the assumption that they are in the correct record. It would be preferable that unless an exact match is made on search criteria, Koha only displays search results rather than going straight into the record, if it is only the closest match. There is still room for error, but this would help shave that rate down a bit. Close or partial matches should not go straight into a record. If you are typing a patron name or number and the suggestions show up, it is on the staff member for picking the right or wrong patron. But if the system is throwing us into a record based on loose information, that is a problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 38677] New: XSLT doesn't follow frameworks
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38677 Bug ID: 38677 Summary: XSLT doesn't follow frameworks Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Users often assume the visibility checkbox on fields on the frameworks will change if it's visible on the OPAC details page. It would be great if we could build/update the XSLT based on those fields (or additional fields for details, search results, for both OPAC and Staff. This would be good for users being able to make changes without access to the XSLT. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27309] New: Add plugin hooks for capturing raw passwords (NNPDB)
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27309 Bug ID: 27309 Summary: Add plugin hooks for capturing raw passwords (NNPDB) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Bug 22706 tried to add hooks to make it possible to implement support for the Norwegian National Patron Database (NNPDB) via a plugin. That bug added a new hook called check_password, and this was called in two places: 1. In Koha::Patron::set_password https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… 2. In Koha::Patron::store https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… The second call to check_password was initially placed after this call: $self = $self->SUPER::store; so we could send both the raw password and the borrowernumber to the hook. This is of course a problem, since checking the password after the borrower has been stored means we can't reject the user completely based on the password. And so the call to the check_password hook was placed bwfore this line. This meant that the check_password hook could not serve the intended purpose of implementing the NNPDB. This bug proposes a new plugin hook, to be implemented after the ->store, to finally make it possible to implement NNPDB as a plugin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 38770] New: Remove @vue/cli-service and babel
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38770 Bug ID: 38770 Summary: Remove @vue/cli-service and babel Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org It's needed for bug 38167 and Bug 38426. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45