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

[Bug 31011] New: Make hold reminders respect patron's language
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31011 Bug ID: 31011 Summary: Make hold reminders respect patron's language Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When running misc/cronjobs/holds/holds_reminder.pl it looks like borrowers.lang is not respected. The only code I can see that relates to language is this: # FIXME What if we don't want to default if the translated template does not exist? my $template_exists = Koha::Notice::Templates->find_effective_template( { module => 'reserves', code => $lettercode, branchcode => $branchcode, lang => 'default', } ); As far as I can see, the "default" template is always used? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41834] New: Remove systempreferences's options, explanation and type DB values
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41834 Bug ID: 41834 Summary: Remove systempreferences's options, explanation and type DB values Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41833 We currently have to set options, explanation and type in sysprefs.sql and the atomic/dbrev files. However we (almost) never use them, we rely on the values in the yml files. We could remove them and don't require them when when add new sysprefs. It will avoid the mess we currently have (mismatch between new and updated installations, see bug 41682 and bug 41800). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41833 [Bug 41833] Use YML description for syspref's search -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 23756] New: Appendix for workflows
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23756 Bug ID: 23756 Summary: Appendix for workflows Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Wondering if the documentation should include workflow examples for different tasks. I know how different each library can be with their workflows, but workflows seem to be a common topic, and there are multiple ways to approach different tasks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 38201] New: VueJS architecture rethink
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 Bug ID: 38201 Summary: VueJS architecture rethink 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 37301 The goal is to streamline and provide a standard to how a regular CRUD component is implemented, instead of having to implement everything every time a new CRUD is required. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37301 [Bug 37301] Further improve how we build Vue components -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 73

[Bug 43155] New: POS breaks on modal if change required
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '26

18 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43155 Bug ID: 43155 Summary: POS breaks on modal if change required Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: martin.renvoize(a)openfifth.co.uk Target Milestone: --- This only happens if the patron is owed change. If we enter in an exact amount tendered, everything works. We are seeing a bug with the POS. If I have an amount owed in the POS, like $1.25, and I enter $2.00 tendered, and press confirm, a modal comes up asking to confirm the change owed. If I press yes, nothing happens. If I run console.log("Koha:", Koha); console.log("Koha.prefs:", Koha?.prefs); directly in the browser console on that page, I get: Koha: { ... } Koha.prefs: undefined It looks like Koha.prefs is not being initialized. If I run this in the console on that page: Koha.prefs = Koha.prefs || {}; Koha.prefs.FinePaymentAutoPopup = false; Then I enter the amount tendered over the amount owed, the confirmation comes up, I press yes, and it works. I temporary workaround I've come up with seems to get us by for the moment: //TEMPORARY Workaround for POS bug - 7/22/26 $(function () { Koha = window.Koha || {}; Koha.prefs = Koha.prefs || {}; }); //TEMPORARY Workaround for POS bug - 7/22/26 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42811] New: Migrate x-koha-embed headers to embed keyword in API clients
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '26

18 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42811 Bug ID: 42811 Summary: Migrate x-koha-embed headers to embed keyword in API clients 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 Depends on: 36369 Target Milestone: --- Bug 36369 introduced KohaApiClient with a _resolveEmbed() method that translates an embed parameter into the x-koha-embed header automatically. Several API client files still use the old pattern of manually setting the header: headers: { "x-koha-embed": "field1,field2" } These should be migrated to: embed: ["field1", "field2"] Files to migrate: - acquisition-api-client.js - authorised-values-api-client.js - checkout-api-client.js - erm-api-client.js - ill-api-client.js - preservation-api-client.js - sip2-api-client.js Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36369 [Bug 36369] Make APIClient be more useful -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

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

18 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 59

[Bug 40537] New: Sum total cost in ordered / foreign currency on invoice summary page
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '26

18 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40537 Bug ID: 40537 Summary: Sum total cost in ordered / foreign currency on invoice summary page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org On the invoice summary, the individual prices in the foreign currency are now shown, however there is no total for the foreign currency prices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42995] New: Error in table of pending orders prevents receiving orders
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '26

18 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42995 Bug ID: 42995 Summary: Error in table of pending orders prevents receiving orders Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Found while testing bug 40575 and confirmed by David on main: [ERROR] GET /api/v1/acquisitions/orders: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'biblio.biblionumber' in 'WHERE' at /kohadevbox/koha/Koha/Objects.pm line 401>> 1. Add an order to the bask for My Vendor. 2. Close the basket 3. Go the vendor page 4. Click 'Receive shipments' 5. Enter an invoice number 6. Click 'Next' 7. You get a "Something went wrong when loading the table. 500: Internal Server Error." Click OK 8. The 'Receive orders from My Vendor" page sits on "Processing ....". 9. There is the error above in the plack-api-error.log -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 40575] New: Transferring order will reload the page and its form
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '26

18 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40575 Bug ID: 40575 Summary: Transferring order will reload the page and its form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Test plan: 1 - Create two baskets: "Source Basket" and "Dest Basket" 2 - Add one command line to "Source Basket" 3 - Close the basket 4 - Receive shipment 5 - Receive order 6 - Cancel the order receive 7 - Transfer the order to the Dest Basket -> When clicking on chose, you will be asked if you want to send again infos (which were sent to cancel the order receive), and if accepting, you will be printed an error. 8 - Apply patch 9 - Repeat the process with another source Basket and notice the page is simply reloaded without sending form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21