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

[Bug 24414] New: Can't add/delete funds with only budget_add_del permission
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24414 Bug ID: 24414 Summary: Can't add/delete funds with only budget_add_del permission 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is very minor, but I was trying out all the permissions to better document them in the manual and I found something weird. There are several permissions granting access to funds. - budget_add_del described as 'Add and delete funds (but can't modify funds)' - budget_manage described as 'Manage funds' - budget_manage_all described as 'Manage all funds' - budget_modify described as 'Modify funds (can't create lines but can modify existing ones)' If I only have budget_add_del, I can't create or delete funds. I have to have budget_manage to access the funds administration page. Which is ok, I can simply add a note in the manual that budget_add_del requires budget_manage. If I have budget_add_del and budget_manage, I have access to the funds administration page, but not the 'New fund' button nor the 'Actions' button to delete an existing fund. So in reality, I can't add nor delete funds... If I have budget_manage and budget_modify (but not budget_add_del), I can't add new funds I can't edit existing ones, but I can delete them. To test : 1) Create a patron and give them the catalogue permission and the budget_add_del permission 2) Log in with this patron (I use a private window to be able to go back and change their permissions later without logging out again) 3) Go to the Acquisitions page 4) Notice you can see the budget, but you can't click on the fund code and you don't have the 'Funds' link in the left menu 5) Go back to edit the user's permissions and grant them budget_manage; save 6) Go back to the Acquisition page with the limited patron (refresh if needed) 7) Notice that you can now click on the fund code and you have a 'Funds' link on the left side of the screen 8) Click on the fund code 9) Click on 'New' and choose 'Add fund for xx'; add the new fund 10) Notice there is no 'Actions' button from which you can delete this fund 11) Go back to edit the user's permissions and remove the budget_add_del permission and add the budget_modify; save 12) Go back to the Acquisition page with the limited patron (refresh if needed) 13) Click on the 'Actions' button and choose 'Edit'; the page refreshes, but nothing happens 14) Click on the 'Actions' button and choose 'Delete' and confirm; the fund is deleted I have trouble imagining a situation where we would want staff to be able to add and delete funds but not modify them, so that's why I said I think this is minor. I think in most cases, the staff member will have at least all three (budget_add_del, budget_manage and budget_modify). But I still wanted to record the weirdness somewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32919] New: Patron category transitions should be managed in the interface, not on the command line
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32919 Bug ID: 32919 Summary: Patron category transitions should be managed in the interface, not on the command line 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: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a library wants to configure transitions between patron categories using the update_patrons_category.pl cron, all of the parameters for this must be entered on the command line. We should put the power to configure this in the hands of the library, and allow configuring these transitions in the Patron Category editor within the interface. We'll still need the cron of course, to do the actual shifting, but how cool would it be to have one job that checks the categories preferences and does the work without needing several job definitions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42759] New: Hidding fields or subfields with "Flagged" checkbox or in hidding all views in MARC framework do not work well.
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42759 Bug ID: 42759 Summary: Hidding fields or subfields with "Flagged" checkbox or in hidding all views in MARC framework do not work well. Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the configuration of a MARC framework, the "Flagged" function, intended to prevent a subfield from appearing in the OPAC, in the editor, or in the intranet, does not seem to behave as expected. Fields or subfields who's "Flagged" has been checked should not appear anywhere, even if the fields are not empty. However, we see these fields appearing in the editor, in the MARC view of the OPAC, and on the intranet (even if all subfields are flagged). Also, if I leave all the boxes unchecked so that they do not appear anywhere (the same behavior as "Flagged", according to the Koha manual), I still see the information in the editor and on intranet if a subfield is filled (if it is empty, I no longer see the field). This is therefore in contradiction with the Koha manual. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42753] New: item-api-client.js: items.get() should accept headers parameter instead of hardcoding x-koha-embed
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42753 Bug ID: 42753 Summary: item-api-client.js: items.get() should accept headers parameter instead of hardcoding x-koha-embed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com ItemAPIClient.items.get(id) hardcodes x-koha-embed: '+strings' in the request headers. This should be passed through from the caller (like getAll already does) so different consumers can request different embeds. Current: get: id => this.httpClient.get({ endpoint: 'items/' + id, headers: { 'x-koha-embed': '+strings' }, }), Should be: get: (id, params = {}) => this.httpClient.get({ endpoint: 'items/' + id, ...params, }), Callers that need +strings would pass it explicitly: APIClient.item.items.get(id, { headers: { 'x-koha-embed': '+strings' } }) This follows the same pass-through pattern used for bundled_items.add(). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42758] New: Resending notices needs more information
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42758 Bug ID: 42758 Summary: Resending notices needs more information Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk When you resend a notice, the only change to the information on the notice is the updated column. This does not show any reason for the resend or how many times it is resent, or if anything changed from the last time (like the address). It would be helpful if resends were nested and showed the address it was sent to for each attempt. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34134] New: When viewing an authority details page the search bar is defaulted to the current records authority type
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34134 Bug ID: 34134 Summary: When viewing an authority details page the search bar is defaulted to the current records authority type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This was true in previous versions, but is less visible now. To recreate: 1 - Search authorities for "John" 2 - Click on "Uniform title: Jack Johnson" 3 - View the details page, ooooh 4 - Decide to search for John again 5 - This time you get one result? 6 - Click the settings in the search box 7 - Note you have been defaulted to 'Uniform title' authority type -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42266] New: Spelling: URL is an abbreviation
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42266 Bug ID: 42266 Summary: Spelling: URL is an abbreviation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating: Url: %s koha-tmpl/intranet-tmpl/prog/en/modules/admin/usage_statistics.tt:217 -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 42752] New: Add additional patron cardnumber generation strategies to Koha::AutoNumber
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42752 Bug ID: 42752 Summary: Add additional patron cardnumber generation strategies to Koha::AutoNumber Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 22707 introduced Koha::AutoNumber, a generic strategy framework for patron cardnumber (and future item barcode) generation. The framework is designed to be extended by adding new Koha::AutoNumber::* subclasses that override _next_from() and, where needed, db_max(). Three additional strategies have been identified as useful for Koha libraries: 1. Codabar / CLSI The traditional North American library card standard. 14-character format with a Codabar check character. Many libraries still hold physical card stock in this format. Algorithm::CheckDigits supports Codabar, making the implementation straightforward. 2. Prefixed sequential A fixed text prefix followed by a zero-padded sequential counter, e.g. 'LIB0001234' or 'BRANCH001'. Useful for libraries that issue staff cards, student IDs, or branch-coded patron identifiers. Would require one additional system preference for the prefix string. 3. Annual sequential A year prefix followed by a sequential counter, e.g. '2026001234'. Mirrors C4::Barcodes::annual for item barcodes. Useful for academic libraries that issue cohort-coded patron cards. Each strategy is a self-contained subclass; no schema changes are required. Strategies can be implemented and submitted independently. See also: Bug 22707 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 19958] New: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19958 Bug ID: 19958 Summary: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the system preference "automembernum" only allows for the patron's barcode to default the card number field on the patron addition screen to the next available card number (for example, if the largest currently used card number is 26345000012941, then this field will default to 26345000012942). It would be nice for the library to choose the format of the barcode (for example : system preference autobarcode). Then a library could choose to include letters and numbers to their patron's barcode instead of just numbers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

1 0