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

[Bug 43389] Remove conditional TT tags from tables thead (Holdings tables)
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43389 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #430 from Lisette Scheer <lisette(a)bywatersolutions.com> --- Jake, thanks for all your hard work! Here are my testing notes: Following the test plan: https://docs.google.com/document/d/1EeDN9d787zJyN17-86v_owGkbFEn4fyM6iqb3Cz… At 5.2 step 3, if you create with your non-super librarian, there's a link to the background job, but the status doesn't update. Also the sidebar on the displays module page is smaller than the header of the sidebar. At 7.1 & 7.2 step 3, if it's set to 'enabled' it shows the changed values, even if there's a start date in the future or an end date in the past 7.3 works as expected I can't consistently remove the last item from a display. It will look like it did, but then if I open the display again it's still there. This happened both as superlibrarian and more limited staff. Save and continue editing spits you back to the displays page instead of reloading the edit page. Duration seems to autofill on creation to 14 if you leave it empty, even if you set a longer start and end date. It looks like if you remove it on subsequent edits it works as expected. It also fills the dates for today+2 weeks if all the fields are blank. If they aren't required, I'd expect that you could have a date-less display. A number of the columns that have active_display are set: columnname: active_display cannot_be_toggled: 1 cannot_be_modified: 1 is_hidden: 1 It seems odd to me that it's hidden, can't be toggled, and is off. Is that just because it needs to be present for the code to grab it when active? There are a few coding guidelines that need to be met: JS19: Avoid Template::Toolkit tags in script tags JS21: Avoid jQuery for new or refactored code in Koha core ACTN1: New additions to actions logs should use the JSON Diff format https://wiki.koha-community.org/wiki/Coding_Guidelines Additionally some tests fail: [FAIL] t/cypress/integration/Display/Displays_spec.ts FAIL forbidden_patterns forbidden pattern: .only detected (line 443) [SKIP] debian/templates/apache-shared-intranet.conf SKIP new_line_at_the_end_of_file [PASS] display/display-home.pl [SKIP] etc/koha-httpd.conf SKIP new_line_at_the_end_of_file [WARN] installer/data/mysql/atomicupdate/bug_14962-temporary_shelves.pl WARN spelling permenant ==> permanent [SKIP] installer/data/mysql/mandatory/auth_val_cat.sql SKIP new_line_at_the_end_of_file [SKIP] installer/data/mysql/mandatory/userflags.sql SKIP new_line_at_the_end_of_file [SKIP] installer/data/mysql/mandatory/userpermissions.sql SKIP new_line_at_the_end_of_file [SKIP] koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref SKIP new_line_at_the_end_of_file [SKIP] koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/logs.pref SKIP new_line_at_the_end_of_file [WARN] koha-tmpl/intranet-tmpl/prog/js/vue/components/Display/DisplaysResource.vue WARN spelling permenant ==> permanent * Proving /kohadevbox/koha/t/db_dependent/api/v1/displayitems.t FAIL # Failed test '200 OK' # at /kohadevbox/koha/t/db_dependent/api/v1/displayitems.t line 193. # got: '404' # expected: '200' # Failed test 'exact match for JSON Pointer ""' # at /kohadevbox/koha/t/db_dependent/api/v1/displayitems.t line 193. # Structures begin differing at: # $got->{active} = Does not exist # $expected->{active} = 0 # Looks like you failed 2 tests of 11. # Failed test 'get() tests' # at /kohadevbox/koha/t/db_dependent/api/v1/displayitems.t line 228. # Looks like you failed 1 test of 6. /kohadevbox/koha/t/db_dependent/api/v1/displayitems.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests Have you considered sharing the new syspref to HEA? (see bug 23849 and C4/UsageStats.pm) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42681] New: (Bug 34971 follow-up) serials/serials-collection.pl generates error 500
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42681 Bug ID: 42681 Summary: (Bug 34971 follow-up) serials/serials-collection.pl generates error 500 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: baptiste.wojtkowski(a)biblibre.com Depends on: 34971 When working with subscription without superlibrarian permissions the page /cgi-bin/koha/serials/serials-collection.pl?subscriptionid=NNN generates error 500 with an entry: Can't use string ("NNN") as a HASH ref while "strict refs" in use at /usr/share/koha/lib/C4/Serials.pm line 2792. in plack-error.log. This is because can_edit_subscription called in serials/serials-collection.pl (line ~234) requires a hash reference containing data from the subscription table (or an unblessed Koha::Subscription object), and not subscriptionid. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34971 [Bug 34971] Closing a subscription should require edit_subscription permission -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42055] New: Real time holds queue doesn't rebuild when hold from group hold is filled
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42055 Bug ID: 42055 Summary: Real time holds queue doesn't rebuild when hold from group hold is filled Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library is using the real-time holds queue and a hold that is part of a group hold/hyperhold is filled, the queue isn't rebuilt to remove the other titles. To replicate: -Make sure library is using the real-time holds queue. -Create a group hold with multiple items available at one or more libraries. -Note that all available titles show on the holds queue(s) (see bug 42054). -Check an item in to satisfy the hold group. -Re-run the holds queue(s), and note that the other items from the group hold still show. The queue only appears to rebuild once the item that filled the hold is checked out. If a library checks one of the other items from the group in after the hold has been filled, the later item(s) won't trigger. This is correct behavior, but the fact that the other titles from the group still show on the queue is likely to cause significant frustration and confusion for libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43048] Prevent users from completely removing fields from cataloging frameworks that break Koha
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43048 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #949 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Found a few more issues on a follow up review round: Issue #1: Permission migration drops blanket Tools-flag access Before applying patches: 1) Grab 1 patron (using Henry for this example): 2) Give Henry the 'catalogue' and 'tools' permissions. 3) Login as Henry, notice you have correct access to Overdue Notice / Status trigger tool - works fine: http://localhost:8081/cgi-bin/koha/tools/tools-home.pl 4) Confirm why. inside ktd: koha-mysql kohadev -e "SELECT * FROM user_permissions WHERE borrowernumber=19 AND code='edit_notice_status_triggers';" 5) Query returns empty. This is because this patron does not have that specific permission, it has the parent 'tools' permission. 6) Apply patches, run updatedatabase. 7) Check what the migration wrote: koha-mysql kohadev -e "SELECT * FROM user_permissions WHERE borrowernumber=19 AND code='manage_circ_triggers';" Expected: a new row. Actual: still empty, nothing carried over, because the migration only ever reads from user_permissions, and there was never a row there to read 8) Login as that patron, notice you can't see the circulation triggers at: http://localhost:8081/cgi-bin/koha/admin/admin-home.pl Issue #2: itemtype restriction wrongly lifted on return 0) Pick a test opac patron, if using Henry from above remove the permissions 1) http://localhost:8081/cgi-bin/koha/admin/categories.pl, edit the test patron's category, confirm 'Overdue notice required' is set to 'Yes'. 2) Set syspref AutoRemoveOverduesRestrictions to when_no_overdue_causing_debarment. 3) http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl, 'Add new trigger'. Leave 'Library' as 'All libraries' and 'Patron category' as 'All categories', set 'Item type' to 'Books'. For 'Letter' pick ODUE, check 'Email' under 'Transport type(s)', set delay to 5 days, for 'Restricts checkouts' select 'Yes', 'Submit'. 4) Check out barcodes 39999000019186 and 39999000007558 to the test patron (confirm both are itemtype 'Books'). Backdate both due dates 6+ days overdue. 5) perl misc/cronjobs/overdue_notices.pl -n — restricts the patron. 6) Check the patron's 'Restrictions' tab: confirm restricted. 7) Return barcode 39999000019186 only, leave 39999000007558 8) Check the patron's 'Restrictions' tab again. Expected: still restricted (39999000007558 is still overdue). Actual: restriction is gone. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43482] New: Force_checkout permission needed to override uncaptured hold checkouts
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43482 Bug ID: 43482 Summary: Force_checkout permission needed to override uncaptured hold checkouts Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 23909 allows Self-checkout and SIP to circulate an item that has a pending hold. Unfortunately, staff don't have this granularity. Trying to check out an item with a pending hold (even if it is not yet captured or waiting) requires an override, and staff must have the very broad force_checkout permission (force checkout if a limitation exists) in order to circulate. Most libraries choose to circulate items with uncaptured holds to the patron standing in front of them, and because of 23909 it seems that should be set to not require an override. The current workardound is either to give staff broad override permissions, or to suspend a pending hold, check out the item, and then unsuspend the hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42897] New: FilterSearchResultsByLoggedInBranch display should expand and collapse
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42897 Bug ID: 42897 Summary: FilterSearchResultsByLoggedInBranch display should expand and collapse Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- With the new system preference FilterSearchResultsByLoggedInBranch, it would be nice to be able to expand and collapse the view of all holdings at all locations without needing to keep toggling between show items in all libraries and show local items only. When defaulting to show items in all libraries, a popular title with many copies or a magazine like People with many issues and copies can take up most of the screen of search results. Having an expand/collapse display of holdings across the system per bib record in the results would be ideal. For example, A court of thorns and roses large print edition has 2 copies available at the logged in branch, which show in the location column. There are 27 other copies, which show when clicking on an expand button for that bib in the search results. Clicking the button again collapses the results back to the two at the logged in branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 35934] New: Items in transit show as both in-transit and Available on holdings list
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35934 Bug ID: 35934 Summary: Items in transit show as both in-transit and Available on holdings list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 35696 Like bug 35696, this is another missed case where items.transfer should have been switched to transfer in the template. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35696 [Bug 35696] Transit status not properly updated for items advanced in Stock Rotation tool -- You are receiving this mail because: You are watching all bug changes.

1 17