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

[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

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '25

17 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 --- Comment #37 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I wonder if using separate "OPAC views" and the system preference overwrite would also be an approach as a possible workaround? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '25

16 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 --- Comment #36 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #35) > (In reply to Katrin Fischer from comment #33) > > (In reply to Christopher Brannon from comment #30) > > I totally understand the requirement for consortia, but wondering why you > > say this affects your stats. Can you explain how you solved it now or where > > this effect comes from? > That software is no longer an option, so going to Koha's self check, we have > to use the auto login since most library self checks don't have a keyboard > connected. But we only have the option to use one account to login to with > the auto login. So, we can capture stats per branch. As Christopher mentions here, a lot of libraries use AutoSelfCheckID to log into the self-checkout. Since there can only be one AutoSelfCheckID, all checkouts at all the different branches will be checked out from that user. In the stats, this means the branch associated with checkout will always be the same. I've verified this in my own production installs. (Back in 2013, Liz mentioned even worse issues like the circ rules being applied based on the self-checkout user and not the patron. I haven't looked into that, but that's worth looking at too.) -- Locally, we create "Local" system preferences of "AutoSelfCheckID" suffixed with a branchcode, which allows different branches to have different "AutoSelfCheckID". This is a workaround which won't work so well in the Koha community I think. The best place to put it would probably be the "branches" table, but we'll have to consider the security/permissions ramifications of that, since the current permission required is "manage_sysprefs" and it would move to "manage_libraries". Arguably an understandable change but one worth documenting at the very least. Additionally, each branch must startup their self-checkout using a ?branch= parameter. After that initial visit, the branch parameter gets moved into hidden inputs, but a better place to put it would be in the login session of the self-checkout user. It could be nice to require an additional unguessable code as well so that patrons couldn't manipulate the URL to manipulate the branch used. -- You are receiving this mail because: You are watching all bug changes.

1 0