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

[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

[Bug 26779] New: Make desk selection consistent in auth.tt and set-library.tt
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26779 Bug ID: 26779 Summary: Make desk selection consistent in auth.tt and set-library.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicolas.legrand(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, severine.queune(a)bulac.fr When changing libraries in set-library.tt, the desks selection list print only desk. The desk list is printed with a different code from auth.pp but modified by the same javascript. Make the template code consistent and work for both pages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 40148] New: Add ability to set desks as hold pickup locations or non-hold pickup locations
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40148 Bug ID: 40148 Summary: Add ability to set desks as hold pickup locations or non-hold pickup locations 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For some libraries being able to capture a hold (thus removing it from the holds queue/preventing other branches from filling it) without sending the notice because it's not ready for pickup yet. The hold could then be checked in again at a desk that does allow hold pickups. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3