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

[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

[Bug 39326] New: package-dependant title information should be managed at resource level
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39326 Bug ID: 39326 Summary: package-dependant title information should be managed at resource level Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com In ERM we can have an title, say /erm/eholdings/local/titles/8 which belong to 2 packages. For each package I understand Koha will create a "resource" (a rather vague term...) , say /erm/eholdings/local/resources/11 and /erm/eholdings/local/titles/12 Currently the "title" contains bibliographical information (that will never change : the title, publisher, isbn for a book, issn, etc), but also information that depends on the package (the URL, the coverage dates for a serial, a note about access, etc) I believe all those package-level information should be managed at the "resource" level. Other ERM have something like "resource" and use it that way. Clarifying this point could help resolve other difficulties like the management of the kbart or the "biblio list" (some fields will be imported as component of "title", other as components of "resource") What do you think of this proposal ? -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #61 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |25.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add shelving location to holdings table as a separate column
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed --- Comment #60 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to hebah from comment #57) > I like Lucas's idea here: Maybe we can ditch the system preference all > together and just add shelving location as its own column, configued by > Table settings? > > Knocks out a system preference and allows libraries to show or hide it as > they want. Just in case of a misunderstanding: there is no system preference for the staff interface currently (only for the OPAC: OpacLocationOnDetail) and with this patch having the location show below homebranch or holdingbranch is no longer an option. It will now only show in a separate column or not at all depending on table configuration and data. @Lucas: can you please state that clearly for release notes? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39354 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39354 [Bug 39354] Remove unintended Bootstrap 5 change to scroll-behavior -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38369] New: Checkout in ILL module should override circulation rules and suspensions
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38369 Bug ID: 38369 Summary: Checkout in ILL module should override circulation rules and suspensions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com With CirculateILL preference activated, when the ILL module creates an item an tries to check it out to the patron, the checkout is sometimes blocked by circulation rules, overdue loans, or suspensions. This should not be the case: if we ask for a book from an external library, we won't refuse to check it to the patron because he has an overdue loan... It is a blocker for the use of ILL module in my library -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2