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

[Bug 27923] New: Inventory tool should be able to skip lost items
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27923 Bug ID: 27923 Summary: Inventory tool should be able to skip lost items 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the inventory tool, the "Optional filters for inventory list or comparing barcodes" section allows one to filter results to only consider items with certain lost values. However, there isn't an option to only look at items with no lost status. We should have a "Skip lost items" checkbox, as we have "Skip items on loan" and "Skip items on hold awaiting pickup." If a library is reasonably sure that their lost items will not be on the shelf, they should have the option to just not interact with them in inventory. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 37561] New: Wrong problem in inventory if item has withdrawn status
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37561 Bug ID: 37561 Summary: Wrong problem in inventory if item has withdrawn status Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If an item has a withdrawn status and is nevertheless present on shelf and scanned during the inventory, it will be displayed in the table of the inventory report with this comment in "Problems" column : "Missing (not scanned)" This is wrong, the comment should be something like "Withdrawn status but present on shelf" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32328] New: Add ability to specify how long an item stays on a library's holds queue
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32328 Bug ID: 32328 Summary: Add ability to specify how long an item stays on a library's holds queue Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With multi-location libraries that are open varying hours, it would be helpful to be able to specify how long an item appears on a library's hold queue before the item appears on another location's queue. For example, Title A is available at both Library D and Library E. The patron wants to pickup the item at Library D. Library D is closed Saturday and Sunday, but Library E is not. Currently, the item could potentially show on Library E's hold queue. Since it takes three days of transit time to move the item from Library E to Library D, it would be faster to fill the hold from Library D, but because it was moved off Library D's queue, it won't be filled there. It would be nice to be able to specify by Library how long an item will appear on the holds queue for that library before it is moved, and the item is sent from another library. Using Holds Queue Skip Closed (and the other associated sys prefs) does not address this sufficiently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 11989] Ability to configure days no transfers take place to use with holds queue
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11989 Michael Adamyk <michael.adamyk(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.adamyk@bywatersolut | |ions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39364] New: Items that cannot be renewed should not renew with same due date when selected for renewal
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39364 Bug ID: 39364 Summary: Items that cannot be renewed should not renew with same due date when selected for renewal 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: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have certain item types with 0 renewals allowed in their circ rules. When a staff member selects these for renewal from a patron's checkout table or they are re-processed via offline circulation, the items are marked as "renewed" with the same due date. To replicate: 1. Set up a non-renewable item type in the circ rules. 2. Check out an item from that item type. 3. From the patron checkouts table in the related patron's account, select all and renew all. 4. The item that could not be renewed will now show a due date of today instead of the future due date it listed previously. I understand that having the AllowTooManyOverride set to allow may conflict. However, the ideal behavior in the use cases outlined above would be that the item would not attempt to renew, keeping the original due date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39360] New: Acquisition - add subtotals by budget in acqui-home.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39360 Bug ID: 39360 Summary: Acquisition - add subtotals by budget in acqui-home.pl Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, It would be nice in koha to have lines to indicate in the acqui-home.pl page the subtotals by budget instead of having only a total for all the budgets at the end of the table. Thanks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16196] New: Acquisitions Module Not Showing Subtotals
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16196 Bug ID: 16196 Summary: Acquisitions Module Not Showing Subtotals Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Partner reports that when receiving books in the Acquisitions module, subtotals are not identifying which fund they are for. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39358] New: Automatically assign itemId for items created with https://api.koha-community.org/api/v1/biblios/{biblio_id}/items
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39358 Bug ID: 39358 Summary: Automatically assign itemId for items created with https://api.koha-community.org/api/v1/biblios/{biblio_ id}/items Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: urho(a)broomworks.fi QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Correct me if I'm wrong but currently creating new items with POST to /biblios/{biblio_id}/items requires item_id. I think it would be more convenient if item_id could be omitted and the handler would assign items using the auto increment value of items table. Then on the response item_id:s would be populated accordingly. This would prevent potential conflicts when items are being created from multiple sources. Additionally, it seems that item IDs can be manually entered above 2147483647, causing item creation to lock up until the auto-increment value is manually reset. So in a nutshell: 1) Allow item_id to be omitted in POST /biblios/{biblio_id}/items requests. 2) If item_id is not provided, the API should let the database assign it via auto-increment. 3) The response should return the created items with their assigned item_id values. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39355] New: New sample notices are added in English during database migration/Koha upgrade, instead of being transalted
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39355 Bug ID: 39355 Summary: New sample notices are added in English during database migration/Koha upgrade, instead of being transalted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org Full list of sample notices is specified in this file: https://github.com/Koha-Community/Koha/blob/6cffdc70059d04e39507cc94d58c226… It is translatable and used by the installer to fill up the "letters" table with sample notices in our selected languages at the time of Koha installation. However, if a Koha upgrade is ran, database migrations are ran, such as these two: - https://github.com/Koha-Community/Koha/blob/6cffdc70059d04e39507cc94d58c226… - https://github.com/Koha-Community/Koha/blob/6cffdc70059d04e39507cc94d58c226… Unfortunately, these migrations add new notices with sample hardcoded English text of the notice, with a discord of its definition in sample_notices.yml (which might also mean the text is different, if someone adjusts the default in one place but not another). In practice all new notices that were added after the installation are in English, instead of the instance language. Expected behavior: the migrations should add the new notices from sample_notices.yml, in the same language as those set up during the installation. Caveat: I am not sure what determines/saves that primary language. You can have your default OPAC and staff languages be English, your default Linux system locale also be English, while the notices might be another language. I failed to find where that original language might be saved. Also to be clear: this is about the situation where TranslateNotices pref is DISABLED. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 39359] New: Lack of REST API Support for Linking Items to Orders
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39359 Bug ID: 39359 Summary: Lack of REST API Support for Linking Items to Orders Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: urho(a)broomworks.fi QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Currently, the Koha REST API does not provide a way to link items to orders. This functionality would be useful for managing acquisitions and ensuring that items are correctly associated with their corresponding orders. Proposed Changes: 1) Allow specifying order_id when creating or updating items: POST /biblios/{biblio_id}/items: Support an optional order_id field to link the item to an order during creation. PUT /biblios/{biblio_id}/items/{item_id}: Allow updating an existing item to set or change its order_id. 2) Enable batch linking of items to orders: POST /acquisitions/orders/ and PUT /orders/{order_id} should accept an array of item IDs in the request body: {"items": [12345, 12346]} This would allow multiple items to be linked to an order in a single request. 3) Validation Requirement: Ensure that an item is not already linked to another order -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0