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

[Bug 36597] New: Cannot delete circulation desk
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36597 Bug ID: 36597 Summary: Cannot delete circulation desk Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Our CSRF work introduced a problem with deleting circulation desks: The "delete_confirm" does not need "cud-" because it's a GET operation leading to a POSTed deletion after the confirmation is submitted. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 37489] New: Cannot delete patron image without uploading a file
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37489 Bug ID: 37489 Summary: Cannot delete patron image without uploading a file Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've got the upload file field as a required field for patron image, which means that if you try to delete the existing patron image... it won't work because it'll prompt you to upload an image. Basically there is 1 HTML form and there should be 2. Should be an easy fix, but I'm not working on it currently. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 32498] New: Checking an in-transit item out at a branch other than the tobranch should cancel the transfer rather than complete it
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32498 Bug ID: 32498 Summary: Checking an in-transit item out at a branch other than the tobranch should cancel the transfer rather than complete it Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an item is mid-transfer and gets checked out at a branch other than its tobranch, Koha marks the transfer as arrived and edits the tobranch to be the branch at which the checkout happens. This makes for a confusing data trail. Instead, the transfer should be cancelled and the original tobranch should be retained. https://github.com/Koha-Community/Koha/blob/c7a995d28f7ae3759ec9ad377b5f7f2… To recreate: 1: Start a manual transfer of an item from Branch A to Branch B 2: Confirm the item shows as in transit and the branchtransfers table shows frombranch=A, tobranch=B 3: Check item out at Branch A 4: Confirm the branchtransfers table now shows frombranch=A, tobranch=A, has a datearrived value, and has a comment "Forced branchtransfer" (or, if the checkout happens at a third branch) 5: Start a manual transfer of an item from Branch A to Branch B 6: Confirm the item shows as in transit and the branchtransfers table shows frombranch=A, tobranch=B 7: Check item out at Branch C 8: Confirm the branchtransfers table now shows frombranch=A, tobranch=C, has a datearrived value, and has a comment "Forced branchtransfer" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32438] New: Pseudonymized_transactions should include payments and writeoffs
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32438 Bug ID: 32438 Summary: Pseudonymized_transactions should include payments and writeoffs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 24151 The pseudonymization process aims to duplicate the transactional circulation data from the statistics table in a way that does not allow borrowers to be identified. The statistics table also includes entries for payments and writeoffs that contain the borrowernumber of the impacted patron. We should also record payments and writeoffs in pseudonymized_transactions when pseudonymization is enabled. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24151 [Bug 24151] Add a pseudonymization process for patrons and transactions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 38635] New: Improve place hold confirmation page in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38635 Bug ID: 38635 Summary: Improve place hold confirmation page in the OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 175244 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175244&action=e… Screenshot of the current hold confirmation screen I think the current design of the OPAC's hold confirmation page is a little confusing, or at least cluttered. We have the heading "Placing a hold" and then a redundant (at least for sighted users) "Place a hold on" label next to the checkbox. I think we can clean it up a little. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38224] New: Move populate_empty_callnumbers logic into Koha::Biblio for reusability
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38224 Bug ID: 38224 Summary: Move populate_empty_callnumbers logic into Koha::Biblio for reusability 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 34784 introduced an endpoint for populating empty item callnumbers. In order to be able to create a CLI script for the same purpose, it would be positive to migrate that code into Koha::Biblio. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 39174] New: Search::Elasticsearch is end of life and will at some point not be compatible anymore with future versions
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39174 Bug ID: 39174 Summary: Search::Elasticsearch is end of life and will at some point not be compatible anymore with future versions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org tl;dr if someone curious has the time to check if the ES 9 beta works with Search::Elasticsearch , it will help to know if we should immediately worry about Search::Elasticsearch being EOL. If it's not compatible, things will might be a bit tough. (slightly less tl;dr, jump to "Conclusion") Announced here mid 2022 https://github.com/elastic/elasticsearch-perl/issues/220 It got mentioned in Bug 33353 but the issue might have been too distant at the time. And we didn't have any ES 9 preview to works with nor LTS Koha versions to account for. We now have the 1st preview of 9.X, a beta: https://github.com/elastic/elasticsearch/tags If things didn't change much in their workflows, that would mean around half a year before the 9.x release and EOL of 7.x: https://discuss.elastic.co/t/elasticsearch-8-release-date/202759/2 We might think there is still a lot of time before v10 release and v8 EOL. Which is the moment when we would have an issue. Since we have v8 support it's okay. But just with regular Koha versions and even more with LTS, it's important to know if to support v9 it would break v7 compatibility. Because such a major change is not great to do in the life of a Koha release. Like ES 8 support couldn't be backported because it broke ES 6 support. Even if it was EOL, that was an issue. If waiting mid cycle of ES 9, and if Search::Elasticsearch isn't compatible with it. It might be too late to fork it and fix stuff in Koha. Or find another way to communicate with ES (and change even more stuff in Koha which would definitely not be backportable regardless of ES 7 support). By the time it's ready (past ES compat work took time while being simpler), the LTS and maybe also the latest Koha release at the time might be still stuck with official Search::Elasticsearch. And during their lifecycles, ES might be out of date. ES release dates: ES 6: 2017-11 ES 7: 2019-04 ES 8: 2022-02 ES 9: ~2025-10 likely It really depends on how long the time will be between ES 9 and ES 10. We might not have to worry about regular Koha releases unless ES are quick. But if in November 2026 (which is not that far when looking at Bug 25439 for ES 7 in 2020-05. It came into fruition for 22.11 with bug 25669), so if by then we don't support ES 9 (if ES 9 won't work with the current lib), then 26.11 LTS might be stuck with EOL ES 8 before it's own EOL in 2030-05. Which would be for **more than half it's life** if ES 10 comes out in mid 2028 which would be a 2.5 year dev cycle which isn't crazy when looking at the history. Hopefully it keeps getting longer as ES is mature. But no way ES 10 comes as late as 2030. Missing ES 9 support for Koha 26.11 is sure to lead to the issue of having to backport it during it's life which might be problematic if the changes are too big. Conclusion: So despite things seemingly being very far away, with the ES 9 beta now, there is a broom wagon[1] that has started to slowly makes it's way forward. - And with not really pessimistic delay for us to get ES 9 support (which might be especially tough this time) - Our LTS timeline - A not really pessimistic delay between ES 9 and ES 10 We can already foresee that broom wagon catching us before the finish line (the full cycle of Koha 26.11 LTS) (Such dependency management is really Sisyphus cycling and having to stop if not finishing soon enough. And then having to wait for the broom wagon for way longer than they were pedaling! 🙃 Over and over, wondering if they will make it each time. Did I miss something? Is this really our fate? 🤣) [1] https://en.wikipedia.org/wiki/Broom_wagon Or with another analogy, it's early morning, we are hiking and turns out we can already foresee the sun going down before we reach our destination. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37697] New: CSS from HTML customizations previews bleeds through to rest of page
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37697 Bug ID: 37697 Summary: CSS from HTML customizations previews bleeds through to rest of page 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, code in the "Preview" for "HTML customizations" can impact the "/cgi-bin/koha/tools/additional-contents.pl?category=html_customizations" page which is... not good. One suggestion is to use Shadow DOM to encapsulate the previews. I've used this elsewhere in Koha for maximum goodness. We could also try iframes. One way or another, something needs to be done... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 34128] New: Series entry in the 490 field causes the ordering of items to change in the holdings table
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Bug ID: 34128 Summary: Series entry in the 490 field causes the ordering of items to change in the holdings table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The presence of a series entry in the 490 field causes the ordering of items to change in the holdings table. The different ordering is designed to display serial/journal items correctly but it shouldn't be triggered by a 490 entry for a "Books" item type To replicate: 1) In cataloging, click on New record 2) Fill in all the required fields with generic data, ensuring that the 942c field (Koha item type) is "Books" 3) In the 490a field - fill in any string as the Series statement 4) Click save 5) You should now be on the Add item page. We need to add 3+ items, making sure that the Home and Current libraries for each item are in reverse alphabetical order. e.g. Item 1: - Home library: Midway - Current library: Midway Item 2: - Home library: Fairview - Current library: Fairview Item 1: - Home library: Centerville - Current library: Centerville 6) In the top searchbar, find your new item that you have just added 7) On the item detail page, the holdings table will be displaying the items in reverse alphabetical order by library rather than in alphabetical order as it should be by default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18