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

[Bug 42365] New: 775 (Other editions) and 776 (Additional physical formats) should honour $0 like 773
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42365 Bug ID: 42365 Summary: 775 (Other editions) and 776 (Additional physical formats) should honour $0 like 773 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org 773 can use $w or $0 to link to other bib records. To use $w you need UseControlNumber but $0 is honoured without a setting. It would be great for 775 and 776 to also be able to support $0 in the same way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40997] New: Javascript error prevents saving when an instance of an 'important field is deleted
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40997 Bug ID: 40997 Summary: Javascript error prevents saving when an instance of an 'important field is deleted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a record has multiple instances of a field marked as 'important' and a cataloger removes one or more of the instances, and one is left in place, saving the record fails with: Uncaught TypeError: can't access property "getElementsByTagName", elem is null AreFieldsNotOk http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… Check http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… onOption http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… <anonymous> http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… jQuery 2 To recreate: 1 - In Admin - MARC bibliographic frameworks edit the default framewwork and edit 650 tag and mark it as important 2 - Go to cataloging -> new from z39.50 3 - Find a record with mulltiple 650 fields 4 - Delete one of the fields 5 - Attempt to save the record - nothing happens 6 - Check the console log in the browser, see the error noted above -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42435 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42435 [Bug 42435] Many console errors on addbiblio.tt page after content secure policy -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42034] New: Add diff support to system preference action logs
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42034 Bug ID: 42034 Summary: Add diff support to system preference action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging in Koha/Config/SysPref.pm does not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Affected calls in Koha/Config/SysPref.pm: - SYSTEMPREFERENCE/MODIFY or ADD (~line 47): C4::Log::logaction( 'SYSTEMPREFERENCE', $action, undef, $self->variable . ' | ' . $self->value ); (concatenates variable name and new value into a string; no before state) - SYSTEMPREFERENCE/DELETE (~line 63): C4::Log::logaction( 'SYSTEMPREFERENCE', 'DELETE', undef, " $variable | $value" ); System preference changes are important for configuration audit trails. This bug covers updating store() in Koha::Config::SysPref to capture the pre-change value and pass it as $original, and to pass a structured hashref (e.g. { variable => ..., value => ... }) as $infos so the diff mechanism can produce a clear before/after comparison. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42054] New: Group holds and real time holds queue: multiple titles show at once
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42054 Bug ID: 42054 Summary: Group holds and real time holds queue: multiple titles show at once Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(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 multiple items that could satisfy a group hold are available (and all else being equal with transport costs and hold queue priority), all of them show on the holds queue at the same time for libraries using the real-time holds queue. This includes showing on multiple libraries' queues at once if items are available at different holding libraries. This is likely to cause significant frustration with libraries if multiple items are pulled, but then all except one have to be reshelved after the first one triggers to fill the hold. To replicate: -Make sure the library is using the real-time holds queue. -Identify multiple titles that have an available item and no other holds. Items may be at the same location or at multiple branches. -Place a group hold on those titles for a patron. -Note that the holds queue (or queues, if one title is at another branch) lists all of the available titles. Each title is only listed once - so, if Bib A has copies available at Main and North, the title will only show on one library's queue. But if items from Bibs A, B, and C are all available, all of them will show on the holds queue(s). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42431] New: ILL supply: Circulation slowness
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42431 Bug ID: 42431 Summary: ILL supply: Circulation slowness Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Because some circulation actions may trigger ISO18626 messages to be sent to a requesting agency, this can sometimes cause some slowness that otherwise would not happen. The suggestion here is to move those outgoing HTTP requests to a background job instead of halting the application while they're being processed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 16544] New: Changes to circ rules should be logged.
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16544 Bug ID: 16544 Summary: Changes to circ rules should be logged. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At present, changes to circulation rules are not logged. This means that there is no way to determine what circulation rules were in effect at a given time, which makes historical trouble-shooting impossible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 42429] New: Order of moving holds between bibs
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42429 Bug ID: 42429 Summary: Order of moving holds between bibs Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com In testing moving holds between bibs, I moved a hold from one bib that was hold 1 of 3, placed on 02/14/2026. I moved it to a bib with 261 holds, placed between January 2026-March 09 2026. The hold I moved with a date placed of 2/14/2026 ended up in the end of the hold priority. My sense is that this is not intended behavior. Wouldn't the hold file in priority according to the date it was placed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42428] New: Supply ILL - Biblio metadata is only visible in ISO18626 messages
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42428 Bug ID: 42428 Summary: Supply ILL - Biblio metadata is only visible in ISO18626 messages Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com It would be handy and more user friendly if this information was more directly available when viewing the supply ILL and when performing a search to place an ILL hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42426] New: Circulation triggers: inform users of one-at-a-time ruleset editing
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42426 Bug ID: 42426 Summary: Circulation triggers: inform users of one-at-a-time ruleset editing Initiative type: --- Sponsorship --- status: 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: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In the circulation triggers form introduced by Bug 10190, clicking 'Edit' on another row in the rule sets table lets users move from editing the originally selected ruleset to another. This does imply that changes made on the originally selected rule set, if any, are not kept. There isn't a warning or confirmation request - this could be added. Alternatively (or additionally) we could hide or disable the other 'Edit' buttons once a rule set is being edited or created, so the UI reflects the one-at-a-time model. (This would prevent creating the expectation of 'bulk editing', which is not a feature included in 10190) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2