February 2024 - Koha-bugs - lists.koha-community.org

[Bug 35943] New: SQL reports groups/subgroups whose name contains regexp special characters break table filtering
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35943 Bug ID: 35943 Summary: SQL reports groups/subgroups whose name contains regexp special characters break table filtering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Reports Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Groups and subgroups filtering uses regular expressions. The filter looks like "^" + name + "$" The problem is that the special characters in group/subgroup name are not properly escaped, which means that if a name contains "+", "*", or any other regexp special characters, filtering will probably fail. Another (minor) problem is that we use the name to filter instead of the code. So if we have two groups or two subgroups with the same name, it will show reports from both groups/subgroups. There is no reason to have groups/subgroups with the same name, but it is possible (whereas it's not possible to have different groups/subgroups with the same code), so this should be fixed too. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 35921] New: Improve perfs of acqui-home.pl when there are many budgets
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35921 Bug ID: 35921 Summary: Improve perfs of acqui-home.pl when there are many budgets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When there are a lot of budgets with the same owner, most of the time of acqui-home.pl is spent loading the same patron over and over. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 36012] New: ERM/Agreements_spec.ts is failing if run too slow (?)
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36012 Bug ID: 36012 Summary: ERM/Agreements_spec.ts is failing if run too slow (?) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org koha_1 | Running: ERM/Agreements_spec.ts (3 of 13) es_1 | {"type": "server", "timestamp": "2024-02-06T16:59:14,821Z", "level": "WARN", "component": "o.e.c.r.a.DiskThresholdMonitor", "cluster.name": "docker-cluster", "node.name": "9c98971d8b48", "message": "high disk watermark [90%] exceeded on [ZlMDdHYSRcqipOaGsczI_w][9c98971d8b48][/usr/share/elasticsearch/data/nodes/0] free: 2.3gb[5.9%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete", "cluster.uuid": "wwW7XQ57T-SNI8QrMEYbPA", "node.id": "ZlMDdHYSRcqipOaGsczI_w" } koha_1 | <?xml version="1.0" encoding="UTF-8"?> koha_1 | <testsuites name="Mocha Tests" time="67.080" tests="5" failures="1"> koha_1 | <testsuite name="Root Suite" timestamp="2024-02-06T16:59:06" tests="0" file="t/cypress/integration/ERM/Agreements_spec.ts" time="0.000" failures="0"> koha_1 | </testsuite> koha_1 | <testsuite name="Agreement CRUD operations" timestamp="2024-02-06T16:59:06" tests="5" time="67.047" failures="1"> koha_1 | <testcase name="Agreement CRUD operations List agreements" time="0.000" classname="List agreements"> koha_1 | <failure message="Timed out retrying after 5000ms: `cy.wait()` timed out waiting `5000ms` for the 4th request to the route: `getActiveAgreements`. No request ever occurred. koha_1 | koha_1 | https://on.cypress.io/wait" type="CypressError"><![CDATA[CypressError: Timed out retrying after 5000ms: `cy.wait()` timed out waiting `5000ms` for the 4th request to the route: `getActiveAgreements`. No request ever occurred. koha_1 | koha_1 | https://on.cypress.io/wait koha_1 | at cypressErr (http://localhost:8081/__cypress/runner/cypress_runner.js:75187:18) koha_1 | at Object.errByPath (http://localhost:8081/__cypress/runner/cypress_runner.js:75242:10) koha_1 | at checkForXhr (http://localhost:8081/__cypress/runner/cypress_runner.js:134821:84) koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:134844:28) koha_1 | at tryCatcher (http://localhost:8081/__cypress/runner/cypress_runner.js:1807:23) koha_1 | at Promise.attempt.Promise.try (http://localhost:8081/__cypress/runner/cypress_runner.js:4315:29) koha_1 | at whenStable (http://localhost:8081/__cypress/runner/cypress_runner.js:143192:68) koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:143133:14) koha_1 | at tryCatcher (http://localhost:8081/__cypress/runner/cypress_runner.js:1807:23) koha_1 | at Promise._settlePromiseFromHandler (http://localhost:8081/__cypress/runner/cypress_runner.js:1519:31) koha_1 | at Promise._settlePromise (http://localhost:8081/__cypress/runner/cypress_runner.js:1576:18) koha_1 | at Promise._settlePromise0 (http://localhost:8081/__cypress/runner/cypress_runner.js:1621:10) koha_1 | at Promise._settlePromises (http://localhost:8081/__cypress/runner/cypress_runner.js:1701:18) koha_1 | at Promise._fulfill (http://localhost:8081/__cypress/runner/cypress_runner.js:1645:18) koha_1 | at <unknown> (http://localhost:8081/__cypress/runner/cypress_runner.js:5450:46) koha_1 | From Your Spec Code: koha_1 | at Context.eval (webpack://koha/./t/cypress/integration/ERM/Agreements_spec.ts:119:11)]]></failure> koha_1 | </testcase> koha_1 | <testcase name="Agreement CRUD operations Add agreement" time="30.510" classname="Add agreement"> koha_1 | </testcase> koha_1 | <testcase name="Agreement CRUD operations Edit agreement" time="6.377" classname="Edit agreement"> koha_1 | </testcase> koha_1 | <testcase name="Agreement CRUD operations Show agreement" time="4.285" classname="Show agreement"> koha_1 | </testcase> koha_1 | <testcase name="Agreement CRUD operations Delete agreement" time="8.038" classname="Delete agreement"> koha_1 | </testcase> koha_1 | </testsuite> koha_1 | </testsuites> I do not recreate locally, is it because we need to extend the timeout? -- You are receiving this mail because: You are watching all bug changes.

1 56

[Bug 29522] New: Bib record not correctly updated when merging identical authorities with LinkerModule set to First Match
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29522 Bug ID: 29522 Summary: Bib record not correctly updated when merging identical authorities with LinkerModule set to First Match Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1 - have LinkerModule set to First Match 2 - have a bib with its author linked to an authority 3 - duplicate that authority, confirm that an authority search for your author brings up two identical authorities, one linked to your bib 4 - merge the two authority records, telling Koha to keep the newer of the two (the one not linked to your bib) 5 - search authorities for your author again, confirm you see just one authority and it's not linked to any bibs 6 - reload your bib, see the 100$9 contains the number for the authority you deleted in the merge 7 - edit your bib to correctly link it to the remaining authority 8 - set LinkerModule to Default 9 - repeat steps 3 and 4 10 - see your remaining authority is linked to your bib, the bib has the correct authority number I'm not able to replicate this in master. I'm not sure what changed from 21.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 36066] New: REST API: We should not allow deleting open order lines
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36066 Bug ID: 36066 Summary: REST API: We should not allow deleting open order lines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: tomascohen(a)gmail.com See also bug 10869 and bug 18360. Until now we focused on not deleting order lines in the interface entirely. So it is quite strange that we allow it without any checks on the REST API. In harmony with 18360 we should check if the status is cancelled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 36103] New: "Cancel hold" link broken for item level holds
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36103 Bug ID: 36103 Summary: "Cancel hold" link broken for item level holds Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lasse.pouru(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com 1. Open the "Holds" tab of a record with an item level hold. 2. Select a patron from the patron search. 3. Click on the "Cancel hold" link. (Link appears as it should, e.g. "modrequest.pl?CancelBiblioNumber=58&CancelBorrowerNumber=5&CancelItemnumber=125"). 4. Popup appears. Click "Confirm cancellation". 5. Page loads. Instead of the correct data for the hold to cancel, all of the values in the URL are null, i.e. "request.pl?action=cancel&borrowernumber=undefined&biblionumber=undefined&reserve_id=undefined". The hold is not cancelled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 36056] New: Clarify subpermissions check behavior in C4::Auth
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36056 Bug ID: 36056 Summary: Clarify subpermissions check behavior in C4::Auth Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Looking at C4::Auth::haspermission, it looks like it allows checking: { perm => { subperm_a => 1, subperm_b => 1 } } treating it like subperm_a AND subperm_b. But this use case is not documented. We should add tests and add it to the POD. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 36010] New: Items/AutomaticItemModificationByAge.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36010 Bug ID: 36010 Summary: Items/AutomaticItemModificationByAge.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 32029 koha_1 | # Failed test 'ToggleNewStatus: conditions on biblio' koha_1 | # at t/db_dependent/Items/AutomaticItemModificationByAge.t line 356. koha_1 | # got: 'agefield_new_value' koha_1 | # expected: 'new_updated_value_biblio' koha_1 | # Looks like you failed 1 test of 20. Koha_Master_My8/1279 First failure from this one that has been pushed recently. I don't recreate locally (even using MySQL8). Maybe something to do with the age comparison if the node is slow? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32029 [Bug 32029] Automatic item modifications by age missing biblio table -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 35125] New: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35125 Bug ID: 35125 Summary: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com Setup: * Set AutoCreateAuthorities to generate, AutoLinkBiblios to Do, CatalogModuleRelink to Do (and EnableAdvancedCatalogingEditor to enable if you want to make your life easier) * Ensure that LinkerConsiderThesaurus is at the default Don't * Make sure you don't have a genre authority record for Boring stories Add the following headings to a bib record and save it 655 _ _ ‡aBoring stories 655 _ 0 ‡aBoring stories 655 _ 4 ‡aBoring stories 655 _ 7 ‡aBoring stories‡2gsafd 655 _ 7 ‡aBoring stories‡2lcgft Note that you now have each heading linked to a different authid, and you have five genre authority records for Boring stories, all identical. If instead you already had a Boring stories authority record (no matter the thesaurus) before saving the record, they would have all been linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 29087] New: Holds to pull list can crash with a SQL::Abstract puke
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29087 Bug ID: 29087 Summary: Holds to pull list can crash with a SQL::Abstract puke Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Opening the holds to pull list page can crash with the following logged error: SQL::Abstract::puke(): [SQL::Abstract::__ANON__] Fatal: SQL::Abstract before v1.75 used to generate incorrect SQL when the -NOT IN operator was given an undef-containing list: !!!AUDIT YOUR CODE AND DATA!!! (the upcoming Data::Query-based version of SQL::Abstract will emit the logically correct SQL instead of raising this exception) at /usr/share/koha/lib/Koha/Objects.pm line 145 I've traced this to Koha::Holds->get_items_that_can_fill(). Among other things, this routine fetches a list of item types that cannot fill holds, i.e., cases where the 'holdallowed' rule value is 'not_allowed'. However, if your default rule is to not allow holds, the @hold_not_allowed_itypes list will end up including an entry whose value is undef. When passed to the item query, doing the -not_in filter on itype will result in the crash listed above. A quick fix might be to filter out undef from that list. That will fix the crash, but could lead to incorrect results if the default policy is to deny holds for all item types except for ones that are going to be specifically permitted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56