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

[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 20570] New: Add script to complete scanned article requests
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20570 Bug ID: 20570 Summary: Add script to complete scanned article requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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

[Bug 41045] New: Suggestions manage permissions added to patrons who previously had no permissions in that category
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41045 Bug ID: 41045 Summary: Suggestions manage permissions added to patrons who previously had no permissions in that category Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 33363 separated suggestions_manage permission in three permissions for creating, updating, and deleting suggetions. In bugs test plan and in its atomicupdate file it is stated that these permissions should have been added only for those users who previously had suggestions_manage permissions. However there is a typo on SQL insert statement and new permissions have been added to all users with full catalogue permissions: >INSERT IGNORE INTO user_permissions (borrowernumber, module_bit, code) SELECT borrowernumber, 12, 'suggestions_create' FROM borrowers WHERE flags & (1 << 2) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36