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

[Bug 16122] New: Item record needs to keep Local Use count
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16122 Bug ID: 16122 Summary: Item record needs to keep Local Use count Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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 Like the "issues" field in the items table, there should be a field for "local_use" to keep the count of local uses. While this information is kept in the statistics table, it is a task to acquire, and if a library wants to keep bloat down on their tables, the statistics are pruned on a regular schedule, which means loss of valuable data. This counter would keep that valuable information in one field in each item record, rather than having a separate field for each instance in the statistics table. Unless it is vital to someone to know the exact moment a local use occurred, I am suggesting that this piece of information not be recorded in the statistics table any longer. This would significantly reduce the growth of the statistics table in general. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 164

[Bug 39882] New: Add phone number masking option
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39882 Bug ID: 39882 Summary: Add phone number masking option Change sponsored?: --- Product: Koha Version: Main 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice it we should add a mask for phone number fields. For certain things, like Twilio, it is important that a phone number gets set in an exact format. We have Maskito for date entry, we might be able to leverage that for phone numbers: https://maskito.dev/recipes/phone -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 36167] New: SMSnumber wont show up on the quick add form
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36167 Bug ID: 36167 Summary: SMSnumber wont show up on the quick add form 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Add a value to SMSSendDriver 2. Add smsalertnumber to the PatronQuickAddFields field 3. Quick add a patron, so SMS number field appears -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37570] New: Add possibility to send request on other url defined by a new syspref SearchAlsoIn
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37570 Bug ID: 37570 Summary: Add possibility to send request on other url defined by a new syspref SearchAlsoIn Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello Like OPACSearchForTitleIn I would like to purpose you a new syspref "SearchAlsoIn" which adds the possibility of defining urls to launch the query on other sites. This can be added on both sides (personal pages and OPAC results pages). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 39936] New: Configure blocks per action and per interface in restriction types
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39936 Bug ID: 39936 Summary: Configure blocks per action and per interface in restriction types Change sponsored?: --- Product: Koha Version: Main 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23681 We should make patron restriction types more configurable. Within each restriction type, one should be able to choose whether to allow or block any of a list of actions from any of a list of interfaces. Actions to allow or block: - checkout - renewal - hold - ILL request - purchase suggestion Interfaces to allow or block each action via: - intranet - koha OPAC - SIP - API Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 [Bug 23681] Make patron restrictions user definable -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 36890] New: Add ability to limit purchase suggestion when fines are over a threshold
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36890 Bug ID: 36890 Summary: Add ability to limit purchase suggestion when fines are over a threshold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries would like the ability to block users from suggesting if they have fines/fees above a threshold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

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

10 Nov '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 60

[Bug 32970] New: Allow export of batch item modification results in background jobs
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32970 Bug ID: 32970 Summary: Allow export of batch item modification results in background jobs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bath item modification results present the user with a DataTable containing the results. Other tables in Koha can be exported, we should add that feature to this page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 34210] New: ISSUEQSLIP should offer checkout session items only
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34210 Bug ID: 34210 Summary: ISSUEQSLIP should offer checkout session items only 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha needs to have some mechanism in place to track items a patron checked out in a particular session (this information clears every time a new patron is loaded. Maybe linked to when the last patron button is updated). It would then be helpful in being creating some kind of mechanism so that ISSUEQSLIP could print just the items you just checked out rather than everything today, or everything currently checked out altogether. I can narrow down something close to this session with some template toolkit and time logic, but that is rather complicated for some libraries, and isn't foolproof. It would be preferred if Koha kept track of checkout sessions and offered an easy to implement option in the slip template. This is very needed and common. You don't go the grocery store and get a receipt for everything you bought that day. Just for that transaction. This would line up with current practices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 38252] New: Zebra's Record-control-number does not include $w for 760, 762, 765, 767, 786, 788
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38252 Bug ID: 38252 Summary: Zebra's Record-control-number does not include $w for 760, 762, 765, 767, 786, 788 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org INCLUDED 770 772 773 774 775 776 777 780 785 787 NOT INCLUDED 760 762 765 767 786 788 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5