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

[Bug 37384] New: 500 error when creating/editing patrons with mandatory patron attribute and field collapsed
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37384 Bug ID: 37384 Summary: 500 error when creating/editing patrons with mandatory patron attribute and field collapsed 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Add a patron attribute and mark it as mandatory.2 2. Add 'Additional attributes and identifiers' to the CollapseFieldsPatronAddForm sys pref 3. Try to create a new patron or edit an existing one. 4. 500 error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 40095] New: It would be beneficial to send the page when calling intranet_js plugin hooks
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40095 Bug ID: 40095 Summary: It would be beneficial to send the page when calling intranet_js plugin hooks Change sponsored?: --- Product: Koha Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P1 - high Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk We have the intranet_js plugin hook to allow adding javascript to all intranet pages.. it would be great to have the specific page the hook is called from get passed so we can optionally run code to generate and return the JS instead of returning it for all pages. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 39142] New: Add debug permission to allow user to toggle JS and CSS customizations on/off
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39142 Bug ID: 39142 Summary: Add debug permission to allow user to toggle JS and CSS customizations on/off Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 Depends on: 14004 We all love bug 14004 and its fun tools for loading pages without JS or CSS from sysprefs. We'd like to extend that idea to toggles that would appear on every page to turn UserJS and UserCSS on and off. We'd tie those toggles to a new "debug" permission, so only users with that permission will be shown those toggles. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14004 [Bug 14004] Add ability to temporarily disable added CSS and Javascript in OPAC and interface -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 63

[Bug 41017] New: Show if item is on hold even if OverduesBlockRenewing is on
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41017 Bug ID: 41017 Summary: Show if item is on hold even if OverduesBlockRenewing is on Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I've had a comment by a library that uses OverduesBlockRenewing as well as AllowRenewalLimitOverride (and AllowRenewalOnHoldOverride) that when the item is overdue, the fact that it's on hold is not displayed in the patron's checkouts. Their issue is that while they don't want patrons renewing overdue items from the OPAC, they sometimes override the renewal in the staff interface, but end up unknowingly renewing something that is on hold... To recreate in main: 1. Go to a patron's account and checkout with a past date to create an overdue checkout 2. Place a hold for the same item for another patron 3. View the first patron's checkouts --> In the "Renew" column, it says "On hold" 4. Enable AllowRenewalOnHoldOverride 5. Go back to the patron's checkouts --> The "Renew" column should still say "On hold" 6. Check the "Override renewal restrictions" box --> A check box appears in the "Renew" column, which still displays "On hold" nonetheless 7. Enable OverduesBlockRenewing ("block renewing for all the patron's items") (I think both blocks should work in this scenario, but the library has it set to all) 8. Enable AllowRenewalLimitOverride 9. Go back to the patron's checkouts --> The "Renew" column displays "Not allowed: overdue" (OK) No mention of on hold (NOT OK?) 10. Check the "Override renewal restrictions" box --> A check box appears in the "Renew" column (OK), still no mention of on hold (NOT OK?) The "On hold" mention should be displayed whether or not the item is overdue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 41614] New: additional_contents REST endpoint broke the display location filter
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41614 Bug ID: 41614 Summary: additional_contents REST endpoint broke the display location filter Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 39900 Following the addition of Bug 39900 the "display location" filter in the sidebar of the HTML customizations page is empty. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39900 [Bug 39900] Add public REST endpoint for additional_contents -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 42053] New: Bug 37893 DBUpdate does not always add the new userflags/permissions
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42053 Bug ID: 42053 Summary: Bug 37893 DBUpdate does not always add the new userflags/permissions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In db_revs/250600035.pl for the SIP2 module there is: unless ( -f $SIPconfigFile && -r $SIPconfigFile ) { say_warning( $out, "Skipping migration. SIP config file not found or unreadable" ); return; } and then later: $dbh->do( q{INSERT IGNORE INTO userflags (bit, flag, flagdesc, defaulton) VALUES (31, 'sip2', 'Manage SIP2 module', 0) } ); So the permissions are only added if there is a SIP config. The permissions should be added no matter what. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 41438] New: Batch hold tool: Suspended holds are unsuspended when making other changes to holds
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41438 Bug ID: 41438 Summary: Batch hold tool: Suspended holds are unsuspended when making other changes to holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org If one modifies suspended holds e.g. changes their pickup library, holds are unsuspended. This happens due error in logic of checking if "Suspend holds" selection is empty. To reproduce: 1. Navigate to Tools->Batch modify holds. 2. Search suspended holds. 3. Select a hold to modify and change it's pickup library, but leave "Suspend holds" selection empty. 4. Press "Modify holds". => Note that hold is now not suspended. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 41798] New: Cannot enable 'passive' mode in File Transports for FTP
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41798 Bug ID: 41798 Summary: Cannot enable 'passive' mode in File Transports for FTP Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At some point in the (S)FTP transports bugs, we missed a patch that updated the controller to recognise 'passive' vs 'passiv' (i.e. the spelling fix) This causes issues when trying to enable the passive mode which is recommended for FTP endpoints. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 41781] New: Holds queue builder ( build_holds_queue.pl ) fails if HoldsQueueParallelLoopsCount is greater than 1
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41781 Bug ID: 41781 Summary: Holds queue builder ( build_holds_queue.pl ) fails if HoldsQueueParallelLoopsCount is greater than 1 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(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 HoldsQueueParallelLoopsCount is set to a value greater than 1, build_holds_queue.pl will fail with the message: Can't locate object method "new" via package "Parallel::ForkManager" (perhaps you forgot to load "Parallel::ForkManager"?) at /kohadevbox/koha/C4/HoldsQueue.pm line 205. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 41603] New: Plugin hook causing DB locks when cancelling holds
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41603 Bug ID: 41603 Summary: Plugin hook causing DB locks when cancelling holds Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The Rapido ILL plugin [1] has a simple `after_hold_action` hook that checks if the current hold is linked to an ILL request [2], and in the positive case, it inserts a row on a `task_queue` table for the action to be processed asynchronously by a separate daemon/worker. Even though the plugin itself is not doing any heavy action on the DB, this causes DB locks that are easily reproducible. This seems to be a core Koha issue as it makes the holds cancelling process (and probably others) rather fragile. To reproduce: 1. Clone Rapido ILL: $ mkdir -p ~/git/koha-plugins && cd ~/git/koha-plugins $ git clone https://github.com/bywatersolutions/koha-plugin-rapido-ill.git rapido-ill 2. Start a KTD instance: $ ktd --proxy --name rapido --single-plugin ~/git/koha-plugins/rapido-ill up -d $ ktd --name rapido --wait-ready 200 3. Install the plugin config $ ktd --name rapido --shell k$ cd /kohadevbox/plugins/rapido-ill/scripts k$ perl bootstrap_rapido_testing.pl k$ restart_all 4. Create a hold for a known patron 5. Run this: k$ perl -e 'use Carp::Always; use Koha::Holds; my $hold = Koha::Holds->find(1);$hold->cancel({cancellation_reason => "OVER_365"})' => FAIL: It takes a while! It eventually fails with a lock wait timeout!: ``` C4::Reserves::_FixPriority(): DBI Exception: DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at /kohadevbox/koha/Koha/Hold.pm line 933 ``` => FACTS: There's a hold, being cancelled. There is no ILL request on the system. The only thing that is happening is that the plugin hook is being called, and is doing this query: ``` MariaDB [koha_cuyahoga]> SELECT me.* FROM illrequests me JOIN illrequestattributes ON illrequestattributes.illrequest_id = me.illrequest_id WHERE illrequestattributes.type = 'hold_id' AND illrequestattributes.value = '1' AND me.backend = 'RapidoILL'; Empty set (0.001 sec) ``` Moving the plugin hook outside the transaction fixes it. [1] https://github.com/bywatersolutions/koha-plugin-rapido-ill [2] Linked means checking if it has an extended attribute with the hold_id value. No FK checks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26