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

[Bug 32453] New: Object methods _result and _resultset methods not available in templates
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '26

19 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32453 Bug ID: 32453 Summary: Object methods _result and _resultset methods not available in templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There are times where it would be really useful to be able to access the underying result or resultset within out templates. However, Template Toolkit itself disallows this, but you can disable this feature by setting the $Template::Stash::PRIVATE package variable to a false value. $Template::Stash::PRIVATE = undef; # now you can thing._private The alternate would be to rename _result and _resultset or just provide non-prefixed aliases as result and resultset respectively. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 34907] New: Load datatables on CMS pages
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34907 Bug ID: 34907 Summary: Load datatables on CMS pages Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice we loaded/could optionally load datatables on custom pages for table consistency. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 33364] New: Stop Holds to Pull report showing items that have been allocated to a recall
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33364 Bug ID: 33364 Summary: Stop Holds to Pull report showing items that have been allocated to a recall Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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 The Holds to Pull report shows an item with a hold if the item is available on the shelf, ready to pull and allocate to the hold. The Holds to Pull should NOT show an item with a hold if that item has already been allocated to a recall (i.e. the recalled item is awaiting pickup and or in transit for a patron). To reproduce: 1. Enable UseRecalls and set the recalls-related circulation rules 2. Check out an item to Patron A 3. Place a hold on the item for Patron B 4. Log into the OPAC as Patron C and search for the item. Place a recall on the item. 5. Go back to the staff interface. Go to Circulation -> Holds to pull 6. Confirm the item shows in the Holds to pull table, with the hold for Patron B 7. Check in the item and confirm the recall as waiting 8. Go back to the Holds to pull page. You could manually regenerate the page but running the cronjob in the terminal misc/cronjobs/holds/build_holds_queue.pl 9. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 34828] New: Add Koha::MetadataExtractor class
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34828 Bug ID: 34828 Summary: Add Koha::MetadataExtractor class Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

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

18 Jun '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 36

[Bug 36046] New: Choose staff interface homepage default action
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36046 Bug ID: 36046 Summary: Choose staff interface homepage default action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the default action for the top search box on the staff interface homepage is "Check out". This makes sense for library staff working at the circulation desk. However, for libraries using a self-checkout module, that might not be the desirable default action. We would prefer to have "Search catalog" as default action on the homepage. Would it be possible to have libraries choose the default action on the homepage? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 29285] New: UI tests: Selenium 4 support
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 Bug ID: 29285 Summary: UI tests: Selenium 4 support Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Now v4 is the default when getting the docker image selenium/standalone-firefox . For Selenium 4, the maintainer of our current perl bindings wrote another client: https://metacpan.org/pod/Selenium::Client -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 18760] New: printable checkin alerts
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18760 Bug ID: 18760 Summary: printable checkin alerts 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Our options right now to display messages at check in are as follow : - put a note in itemnotes, which will display in red in the checked in items table - write something in materials, which will display a proper alert, but dedicated to accompanying materials A new feature is on the way to allow patrons to write notes themselves, on a specific issue but not on the item if i understood correctly, that's bug 14224. This feature will create a new field in the items table: checkin_alert, to allow librarians to have arbitrary alerts displaying at checkin. These alerts will be printable. Use case: the item is an ILL item, and when checking it back in, the librarian wants to have a printed slip with the address of the partner library the item should be sent back to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 25222] New: Add ability to let plugins live in individual subdirectories
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25222 Bug ID: 25222 Summary: Add ability to let plugins live in individual subdirectories Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Tomas: "We really need to put each plugin in its own subdirectory (to identify them individually) and have a metadata file we can refer to." This would make things much more manageable. Right now, plugins get all mixed together in the plugins directory. For example, installing the kitchen sink plugin results in Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm being created in the plugins directory. Installing CoverFlow will create CoverFlow.pm in the same directory as KitchenSink.pm. There is no reason that plugins cannot be created to install in a subdirectory directly in the kpz file. In that case, the plugins directory would contain something like kitchen-sink/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm, while CoverFlow would live in coverflow/Koha/Plugin/Com/ByWaterSolutions/CoverFlow.pm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 36135] New: Add tool to batch edit pick up dates of holds
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36135 Bug ID: 36135 Summary: Add tool to batch edit pick up dates of holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are sometimes situations where libraries have to extend their holds pick up dates. We should at same kind of tool for this like "Batch extend due dates". However criteria for dates to extend can be complicated (we've excluded e.g. items with specific state, holds with found status, items on transfer to specific library). So rather than using predefined criteria for holds to edit (at least for the start), tool should have option to upload file of SQL query results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 268