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

[Bug 36345] New: Deleting related things causes data loss for old_reserves
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36345 Bug ID: 36345 Summary: Deleting related things causes data loss for old_reserves 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The old_reserves table is meant to be a historical preservation of data. Currently it has foreign keys a number of tables where that also have a delete/old table for preservation. For example, we may have an "old reserve" with an associated item. When we delete that item, the item is moved to the deleteditems, and old_reserves.itemnumber is set to NULL thus losing the associated item even though we still have the item data! This is true for borrowers, bibs and items. To enable saving this data, we should add a non FK column for each related table that has a delete/old version of that table. Then, when the associated item is deleted, copy the FK value to the new column before is is nullified. In fact, if we populated those columns when moving the hold from reserves to old_reserves, we wouldn't even have to add code to each of the delete methods! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 5807] Add collection code to circulation rules
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5807 Olli-Antti Kivilahti <olli-antti.kivilahti(a)hypernova.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti@hypern | |ova.fi --- Comment #6 from Olli-Antti Kivilahti <olli-antti.kivilahti(a)hypernova.fi> --- (In reply to Christopher Davis from comment #3) > (In reply to Lisette Scheer from comment #2) > > Hear here to what Lisette said. If an item looks like a book, acts like a > book, and feels like a book, call it a book, not a "New Book" or a "History > Center Material" because that is the only way we can control its circulation. > > Thank you. > This is a big pain point for us too. Typically different locations in the library have different circulation rules, such as "reference shelf", which can contain all kinds of library materials, but need to be made available for daily loans. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 9762] Log circulation overrides
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40866 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40866 [Bug 40866] Weird and untranslatable message appears every time something is checked out -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40864] New: Add grace period to hourly checkout (in minutes)
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40864 Bug ID: 40864 Summary: Add grace period to hourly checkout (in minutes) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.aimee(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com We have on-site loans that are hourly, with a 30-minute grace period before fines incur. Ex. Chromebooks out for 4 hours, $5 hourly fines don't occur until 4.5 hour timestamp. Would love to see grace periods by minute intervals as a feature. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 32307] New: Chocolat image viewer broken in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32307 Bug ID: 32307 Summary: Chocolat image viewer broken in the staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I'm seeing errors in the console when viewing a bibliographic record in the staff interface. Looking at a record with more than one cover image available (e.g. Amazon and Coce) I can click the cover and see the first image in the Chocolat viewer, but there is an error in the console: Uncaught (in promise) <img src="null"> chocolat_22.0600032.js:54:19 When I click the arrow to view the next cover, the cover doesn't load. It appears to fail on the *last* image. If my record has three covers available (e.g. Local, Amazon, and Coce) the first and second images are displayed correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 40627] New: Optionally require choice of hold type being loading holdable items and/or item groups in staff interface
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40627 Bug ID: 40627 Summary: Optionally require choice of hold type being loading holdable items and/or item groups in staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com For bibs with a lot of items, item groups, and holds, the page to place a hold can take a long time based on the amount of data it loads. We could speed things up by first asking if the patron wants a bib/group/item level hold and then only loading the relevant list. We could then paginate that list to avoid loading the whole thing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37600] New: OpacSuppression does not work in Unimarc
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37600 Bug ID: 37600 Summary: OpacSuppression does not work in Unimarc Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org OpacSuppression does not work in Unimarc. If I understood correctly, need to add <index_subfields tag="955" subfields="n"> <target_index>Suppress:w</target_index> <target_index>Suppress:n</target_index> </index_subfields> in https://git.koha-community.org/Koha-community/Koha/src/branch/main/etc/zebr… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 6796] Overnight checkouts taking into account opening and closing hours
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6796 --- Comment #159 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Emily Lamancusa (emlam) from comment #158) > Hmmm...I'm seeing a few errors in this part of the dbrev: > > + my $branches = > + $dbh->selectall_arrayref( "SELECT branchcode FROM > branches", { Slice => {} } ); > + for my $branch (@$branches) { > + my $branchcode = $branch->{branchcode}; > + > + my @indexes = ( 0 .. 6 ); > + for my $i (@indexes) { > + $dbh->do( > + q{ INSERT INTO library_hours (library_id, day) > VALUES ( ?, ? ) }, undef, $branchcode, > + $i > + ); > + } > > > 1. The parameter bindings in the INSERT statement are reversed - the order > in the SQL is (library_id, day), but the order of the parameter bindings is > undef, $branchcode. > > 2. The INSERT statement isn't idempotent - should be INSERT IGNORE > > 3. The dbrev is using a Koha object, which goes against the coding guidelines > > The section of the dbrev that adds the syspref comes after the above > section. I would think #1 would crash the dbrev, which would explain why the > syspref didn't get added...but I'm surprised someone didn't notice it sooner > if that was happening consistently. (Unless someone did notice and there's > already a follow-up that isn't linked - I didn't dig for one.) Great that you had a closer look ! I think that the binding is correct btw. There is always an undef in the middle in those statements (room for attributes hash). The $i is on the next line. Agree with 2 and 3. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40001] New: edit_items permission allows deletion of individual items. Should be separate.
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40001 Bug ID: 40001 Summary: edit_items permission allows deletion of individual items. Should be separate. Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hananmustafaawan(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, the edit_items permission allows a user to delete individual items using the "Action" button on the edit item page. This behavior persists even when the user does not have the delete_all_items permission, which is intended (according to documentation) to manage bulk deletion. This creates a permissions flaw: staff with rights to edit items can also delete items, which may not always be desirable from a library’s operational or security perspective. Steps to Reproduce: Create a staff account with only the edit_items permission (without delete_all_items) Go to: catalogue/itemsearch.pl Edit an item (via cataloguing/additem.pl?op=edititem&...) Click the Action button, then Delete the item The item is deleted successfully — despite lacking delete_all_items permission Expected Behavior: There should be a separate delete_items permission for deleting individual items OR Deleting any item (individual or bulk) should require the delete_all_items permission. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 6796] Overnight checkouts taking into account opening and closing hours
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6796 --- Comment #158 from Emily Lamancusa (emlam) <emily.lamancusa(a)montgomerycountymd.gov> --- Hmmm...I'm seeing a few errors in this part of the dbrev: + my $branches = + $dbh->selectall_arrayref( "SELECT branchcode FROM branches", { Slice => {} } ); + for my $branch (@$branches) { + my $branchcode = $branch->{branchcode}; + + my @indexes = ( 0 .. 6 ); + for my $i (@indexes) { + $dbh->do( + q{ INSERT INTO library_hours (library_id, day) VALUES ( ?, ? ) }, undef, $branchcode, + $i + ); + } 1. The parameter bindings in the INSERT statement are reversed - the order in the SQL is (library_id, day), but the order of the parameter bindings is undef, $branchcode. 2. The INSERT statement isn't idempotent - should be INSERT IGNORE 3. The dbrev is using a Koha object, which goes against the coding guidelines The section of the dbrev that adds the syspref comes after the above section. I would think #1 would crash the dbrev, which would explain why the syspref didn't get added...but I'm surprised someone didn't notice it sooner if that was happening consistently. (Unless someone did notice and there's already a follow-up that isn't linked - I didn't dig for one.) -- You are receiving this mail because: You are watching all bug changes.

1 0