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

[Bug 43772] New: Possible to create simultaneous duplicate holds with double-click on Place hold button in staff interface
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43772 Bug ID: 43772 Summary: Possible to create simultaneous duplicate holds with double-click on Place hold button in staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- To recreate: 1. Go to a record and select a patron account to place holds. 2. Double-click the place hold button for a bib-level hold. 3. See patron account has two holds. 4. Look at action logs (if on) and see holds have same hold-created timestamp and same starting priority, indicating the requests went through simultaneously, though they will sort into n and n+1 on the patron record. The button should be disabled after first click to prevent these duplicate holds, especially if libraries allow staff to override hold via AllowHoldPolicyOverride where inadvertent overrides of single-hold policy may be happening. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43483] New: Authority linker treats the same name heading differently in 6XX vs 1XX/7XX
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43483 Bug ID: 43483 Summary: Authority linker treats the same name heading differently in 6XX vs 1XX/7XX Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When LinkerConsiderThesaurus is enabled, the authority linker treats a name heading differently depending on whether it appears in a name field (100/110/111/700/710/711 etc, where MARC21's 2nd indicator is undefined) or in the equivalent name-used-as-subject field (600/610/611 etc, where the 2nd indicator encodes the subject thesaurus). C4::Heading::MARC21::parse_heading only computes a 'thesaurus' value for 6XX tags: my $thesaurus = $tag =~ m/6../ ? _get_subject_thesaurus($field) : undef; # We can't know the thesaurus for non-subject fields C4::Heading::_search then only adds a thesaurus constraint to the authority match query when $thesaurus is defined: if ( $check_thesaurus && $thesaurus ) { push @marclist, 'thesaurus'; ... } So the same person can end up matched to, or auto-creating, two separate authority records from the same bibliographic record: one for their 100 field (no thesaurus constraint, matches/creates against auth_type PERSO_NAME alone) and a different one for their 600 field (thesaurus constraint applied, even when indicator 2 is blank, which is treated as the placeholder thesaurus 'notdefined'). The two authority records end up with identical headings, so Koha's own duplicate-authority detection later flags them as duplicates when a cataloguer tries to merge or link them manually, even though the automatic linker created them as two separate records in the first place. This is not a new regression. Bug 33277 (2023) deliberately made thesaurus undef for non-6XX tags, to stop 100/700 fields failing to match authorities that had no thesaurus recorded at all. Its commit message notes the trade-off explicitly: "this means that Koha does not support multiple thesaurus records for authorities outside of subjects." Nobody has revisited the resulting asymmetry between a name field and the same auth_type used as a subject field. This was reported by a customer after bug 31925 made the 6XX-vs-thesaurus distinction more reliable (correctly coding 008/11 for FAST/MeSH/etc on newly created authorities), which appears to have made this pre-existing asymmetry more visible: a blank indicator 2 on a 600 is still treated as thesaurus 'notdefined' and still gets the thesaurus filter applied during matching, unlike the 1XX/7XX occurrence of the exact same name. Test plan: 1. Turn on LinkerConsiderThesaurus, AutoLinkBiblios and AutoCreateAuthorities. 2. Catalogue a bibliographic record with the same personal name in both a 100 (or 700) field and a 600 field, e.g.: 100 1_ $a Goddard, Giles 600 1_ $a Goddard, Giles $x Criticism and interpretation (blank/undefined 2nd indicator on the 600, i.e. no thesaurus recorded) 3. Save the record, with no existing matching authority in the catalogue. 4. Note that two separate authority records are created for "Goddard, Giles" -- one from the 100, one from the 600. 5. Try to manually merge or link the two authorities together in the Authorities module. Observe that Koha's duplicate detection considers them duplicates of each other, confirming they should have matched to a single authority in the first place. Related bugs: Bug 31925 -- AutoCreateAuthorities needs to preserve subject heading thesaurus. This report surfaced during discussion of that fix; it is not a regression caused by it. Bug 33277 -- Do not search using thesaurus when linking non 6XX fields. Introduced the asymmetry described above, as an accepted trade-off at the time. Bug 39503 -- Linker should always respect thesaurus with LinkerConsiderThesaurus on. Related but narrower: only addresses collapsing 008/11='z' plus 040$f within 6XX-to-6XX matching. Bug 41714 -- MARC21 authorities thesaurus link hardcoded. Touches the same C4::Heading::MARC21 code (the tag-to-auth_type table), but only makes that mapping configurable via frameworks; it does not touch the thesaurus computation or filtering discussed here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 18583] New: Add the ability to merge multiple authorities
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18583 Bug ID: 18583 Summary: Add the ability to merge multiple authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since bug 8064 it is possible to merge multiple bibliographic records at once, it would be nice to be able to do the same thing with authority records. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 43125] New: Rewrite FixPriority to use a single bulk UPDATE instead of per-hold updates
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43125 Bug ID: 43125 Summary: Rewrite FixPriority to use a single bulk UPDATE instead of per-hold updates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Blocks: 43123 Target Milestone: --- C4::Reserves::FixPriority currently issues one UPDATE reserves SET priority = ? per non-captured hold on a biblio, on every hold create, cancel or fill. A popular title with 50 queued holds generates 50 individual UPDATE statements on every state change. The function carries its own FIXME comment noting it needs to be rewritten. Replace the per-hold UPDATE loop with a single bulk UPDATE (for example using UPDATE ... CASE WHEN reserve_id IN (...) THEN ... END, or an equivalent bulk statement), preserving the existing priority ordering semantics exactly. This bug is independent of the REST API and Vue work and can be delivered on its own. Test plan 1. Run t/db_dependent/Reserves.t and confirm all FixPriority related tests pass unchanged. 2. Add a test with a large number of queued holds (50+) and assert the resulting priority values match the pre-patch behaviour. 3. Confirm the number of UPDATE statements issued no longer scales with the number of queued holds. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43123 [Bug 43123] Hold placement workflow: Vue modernisation (epic) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 40256] New: System defined MANUAL debit type description is hard coded but the description can be changed
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40256 Bug ID: 40256 Summary: System defined MANUAL debit type description is hard coded but the description can be changed Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Admin -> Debit types 2. See MANUAL debit type with the description of 'Manual fee' 3. Click edit and edit the description. 4. Go back to the Debit types admin page. The description still reads "Manual fee" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 36540] New: Consider modernising the checkout page to be an Vue page
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36540 Bug ID: 36540 Summary: Consider modernising the checkout page to be an Vue page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The checkouts page is a core function of Koha, The controller has grown very complicated and it can suffer from performance challenges that we keep trying to side step wit preferences work arounds. We should consider working to replace the page with a Vue app and use the modern API's that have been developed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 42598] New: Spent totals on acq homepage and funds page should calculate using quantity received
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42598 Bug ID: 42598 Summary: Spent totals on acq homepage and funds page should calculate using quantity received Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The GetBudgetHierarchy sub from C4/Budgets.pm is used to calculate the Spent amount shown on the acq homepage (/cgi-bin/koha/acqui/acqui-home.pl) and the funds page in admin (/cgi-bin/koha/admin/aqbudgets.pl). This sub calculates using aqorders.quantity rather than aqorders.quantityreceived, which is not strictly accurate. It is possible to receive more items than were ordered, in which case quantity will show the number ordered while quantityreceived will show the number actually received (and therefore the number actually paid for). Note that /cgi-bin/koha/acqui/spent.pl does use quantityreceived, which will lead the two given totals to disagree. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 40901] New: koha-common.service bundles all sub-daemons under one systemd service instead of per-instance services
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40901 Bug ID: 40901 Summary: koha-common.service bundles all sub-daemons under one systemd service instead of per-instance services Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tristin.stagg(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 319

[Bug 42294] New: Tidy all script tags - patron searches
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42294 Bug ID: 42294 Summary: Tidy all script tags - patron searches Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 42094] New: Tidy all script tags
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 Bug ID: 42094 Summary: Tidy all script tags Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41324 On bug 41324 we tidy all the script tags that contained a kohaTable. Now we would like to tidy all the remaining script tags. We will certainly need a comment in the code to flag the script tag that is used to interpolate TT variables into JS variable. ``` <script> // Accept TT tags here let js_variable = [% perl_variable %]; </script> <script> // Here TT tags are prohibided, and ideally the code must be moved to a separate .js file // And we can reuse js_variable </script> ``` Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41324 [Bug 41324] Tidy kohaTable block -- You are receiving this mail because: You are watching all bug changes.

1 174