June 2024 - Koha-bugs - lists.koha-community.org

[Bug 28862] New: Add suffix to name field
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28862 Bug ID: 28862 Summary: Add suffix to name field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Requesting the addition to the name field for suffix entries (Jr., Sr. III, etc.). Ideally it would be a drop-down box that could be prepopulated (auth_value?) with common entries; allowing for cleaner data and easier account viewing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 31391] New: Staff-side recalls
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31391 Bug ID: 31391 Summary: Staff-side recalls Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Add functionality for recalls to be placed via the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 311

[Bug 36369] New: Make APIClient be more useful
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36369 Bug ID: 36369 Summary: Make APIClient be more useful Change sponsored?: --- Product: Koha Version: master 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I file this report for discussion. In my opinion, there's too much duplicated code on the API client libraries. And the APIClient "class" is just a shortcut to avoid instantiating the module-specific API clients: ```javascript import ERMAPIClient from "./erm-api-client"; ... export const APIClient = { erm: new ERMAPIClient(), ``` Then used everywhere like this: ```javascript import { APIClient } from "../../fetch/api-client.js" ... const client = APIClient.erm await client.agreements.count().then( ``` IMHO, we need a real APIClient class that would implement generic methods like: ```javascript create: params => this.post({ endpoint: params.endpoint ? params.endpoint : "/", body: params.resource, headers: params.headers }), ... getAll: params => this.get({ endpoint: params.endpoint ? params.endpoint : "/", params.query, headers: params.headers, }), ... count: params => this.count({ endpoint: params.endpoint ? params.endpoint : "/", "?" + new URLSearchParams({ _page: 1, _per_page: 1, ...(params.query && { q: JSON.stringify(params.query) }), }), }), ``` and the API Client classes (like ERMAPIClient) should inherit from it, somehow. For doing so, we will face another design roadblock: While I uderstand that ERMAPIClient is a single place to have all the ERM module-needed API actions, it still feels weird from an OOP perspective how things are organized. I feel like we should have individual classes, like: ```javascript export RecordSourcesAPIClient extends APIClient ``` and then have a new type of class along this lines: ```javascript import CitiesAPIClient from "./cities-api-client"; import RecordSourcesAPIClient from "./record-sources-api-client"; ... export const AdminAPIClient = { cities: new CitiesAPIClient(), record_sources: new RecordSourcesAPIClient(), ... }; ``` this way, we will avoid repeating ourselves (less bugs!) and the code is (I expect) more reusable. I also think the `embed` handling should just be a list for the different methods, like: embed: [ 'patron', 'patron.category' ] and generically handled by APIClient. No need to build the headers manually everywhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53

[Bug 29768] New: hidepatronname hides guarantor name on borrower edit screen
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 Bug ID: 29768 Summary: hidepatronname hides guarantor name on borrower edit screen Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref hidepatronname is now hiding the guarantor name on memberentry.pl. This seems like a strange place to enforce that system preference since it's convenient for staff to be able to double check that info when editing patron information and personal information is already showing on that screen. It's not enforced on other patron details screens (such as moremember.pl) and I don't think it should impact patron edit screen either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 30144] New: Add support for EDI GIR:LVT, Servicing instructions, segment
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30144 Bug ID: 30144 Summary: Add support for EDI GIR:LVT, Servicing instructions, segment Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We allow for free text instructions in the EDI FTX segment now, taken from the vendor notes field. But this is at the order level, it would be helpful to add support for the LVT segment at the line level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 73

[Bug 36027] New: search_for_data_inconsistencies.pl - make each section optional
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36027 Bug ID: 36027 Summary: search_for_data_inconsistencies.pl - make each section optional Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: phan-tung.bui(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Modification of the script allows us to choose which test to run instead of running all tests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 146

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 275

[Bug 23269] New: Long hold queues are slowing the service
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 Bug ID: 23269 Summary: Long hold queues are slowing the service 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: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org In Finlands public libraries hold queues can be huge due popular records having a lot of holds at the same time. Most popular records may even have over 1000 holds. This leads the service slowing significantly when browsing their holds page. There should be pagination in the holds table for efficient page loading. -- You are receiving this mail because: You are watching all bug changes.

1 121

[Bug 18523] New: Filter Circulation lists on home library
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18523 Bug ID: 18523 Summary: Filter Circulation lists on home library Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using IndependentBranches, items of other sites should not be seen in this Circulation lists for staff users (except for superlibrairians) : - Holds awaiting pickup - Pending on-site checkouts -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 35729] New: Coce Should Account for New ISBN 979*
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35729 Bug ID: 35729 Summary: Coce Should Account for New ISBN 979* Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kalleen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, I noticed that there was a cover mismatch with a coce_amazon cover because the new 2024 title has an ISBN of 9798885795692 (using the 979 instead of 978). There is an Italian title with an ISBN of 8885795692 that is showing instead. It looks like they have updated the valid ISBN standards: https://isbn.org/about_isbn_standard and it seems like coce should be updated to recognize this new standard and not match 9798885795692 to be the same as 8885795692. Thanks! Kal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 68