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

[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 42545] New: Koha::Calendar::days_between skips holiday subtraction for end date if time is early
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42545 Bug ID: 42545 Summary: Koha::Calendar::days_between skips holiday subtraction for end date if time is early Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: apirak(a)punsarn.asia QA Contact: testopia(a)bugs.koha-community.org Created attachment 198697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198697&action=e… This patch truncates both dates to the beginning of the day after cloning and setting the time zone, ensuring the loop correctly processes all calendar days between the two dates. -- You are receiving this mail because: You are watching all bug changes.

1 21

[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

[Bug 42606] New: Error when importing a record using Z39.50 from the cataloging home page
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42606 Bug ID: 42606 Summary: Error when importing a record using Z39.50 from the cataloging home page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: andrew(a)bywatersolutions.com, angela.berrett(a)familysearch.org, blawlor(a)clamsnet.org, bugzilla(a)koha-us.org, carthur(a)slolibrary.org, cbrannon(a)cdalibrary.org, david(a)davidnind.com, dcook(a)prosentient.com.au, echandler(a)clamsnet.org, george(a)nekls.org, jonathan.druart(a)gmail.com, lauren_denny(a)sil.org, lisette(a)bywatersolutions.com, lucas(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, mike.grgurev(a)mainlib.org, mnero(a)oslri.net, mspinney(a)clamsnet.org, nmumford(a)clamsnet.org Depends on: 32773 >From the cataloging home page, click "New from Z39.50" without choosing a framework in the dropdown menu. Perform a Z39.50 search in the popup window, then click "Import" for one of the results. This triggers an error in the parent window: Can't call method "is_fast_add" on an undefined value at /kohadevbox/koha/cataloguing/addbiblio.pl line 518 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32773 [Bug 32773] Have the ability to have more than 1 Fast Add framework -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30