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

[Bug 38857] New: Cronjobs should log their start and command line parameters before processing options
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38857 Bug ID: 38857 Summary: Cronjobs should log their start and command line parameters before processing options Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When a cronjob is passed bad parameters it may fail. If it does so before logging its start, there is no trace that it was even attempted We should move the logging to before the options are fetched to ease troubleshooting To test: 1 - Enable CronjobLog 2 - On command line: perl misc/cronjobs/cleanup_database.pl --old_reservers 550 3 - Error on command line 4 - In staff client, go to Tools->Log viewer, check 'Cronjobs' and submit 5 - No entries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 38926] New: POST /biblios returns 200 even if AddBiblio fails
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38926 Bug ID: 38926 Summary: POST /biblios returns 200 even if AddBiblio fails Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 31800 For some reasons I POSTed an invalid biblio to /api/v1/biblios it returned {id: null} The biblio record is not created, but the response is 200. 707 my ( $biblio_id ) = AddBiblio( $record, $frameworkcode, { record_source_id => $record_source_id } ); 708 709 $c->render( 710 status => 200, 711 openapi => { id => $biblio_id } 712 ); Obviously we should test $biblio_id Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31800 [Bug 31800] Add POST endpoint for Biblios -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 38929] New: POST endpoints not returning the Location header
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38929 Bug ID: 38929 Summary: POST endpoints not returning the Location header Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com I found `POST /biblios` is not returning it. Opening this bug to track and fix such problems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 41010] New: Incorrect show_priority condition in opac-detail
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41010 Bug ID: 41010 Summary: Incorrect show_priority condition in opac-detail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39276 >From bug 39276 comment 12 I don't understand this patch. Here is the diff: + [% ELSIF show_priority %] + <td class="holds_priority">[% priority | html %] </td> [% END %] Here is the context: [% IF item_level_holds > 0 || show_priority %] <td class="holds_count"> [% IF holds_count.defined %][% ITEM_RESULT.holds_count | html %][% END %] [% IF ITEM_RESULT.priority %] [% IF holds_count.defined %] <span>(priority [% ITEM_RESULT.priority | html %])</span> [% ELSE %] <span>[% ITEM_RESULT.priority | html %]</span> [% END %] [% END %] </td> [% ELSIF show_priority %] <td class="holds_priority">[% priority | html %] </td> [% END %] we never reach the ELSIF, we have || show_priority in the first condition. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39276 [Bug 39276] OPACShowHoldQueueDetails datatable warning -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 39276] New: OPACShowHoldQueueDetails datatable warning
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39276 Bug ID: 39276 Summary: OPACShowHoldQueueDetails datatable warning Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1. Enable Holds history system preference and set the OPACShowHoldQueueDetails to "Show holds and their priority level". 2. Place an item on hold. 3. Log in to your OPAC and go to your Holds history tab. 4. Click on your hold that is marked as "Pending". 5. Notice that a datatable warning appears similar to: "DataTables warning: table id=holdingst - Requested unknown parameter '6' for row 0, column 6. For more information about this error, please see https://datatables.net/tn/4" -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 35202] New: Table Settings change does not hide all serial_notes (OPAC).
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35202 Bug ID: 35202 Summary: Table Settings change does not hide all serial_notes (OPAC). Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org We have multiple subscriptions for some serials and we have public-inappropriate notes which we want to hide. Editing the subscriptionst view of the subscriptions table in OPAC to hide the serial_notes field should make the serial_notes invisible for all subscriptions. It only vanishes from the first subscription displayed. Other subscriptions expose the serial_note data. Hiding the serial_notes via Table Settings should apply to all subscriptions. Related to Bug 22179? (But the data we have there should be elsewhere, so Bug 33298 interests us). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 39406] New: Issues on serial collection page sort from old to new now
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39406 Bug ID: 39406 Summary: Issues on serial collection page sort from old to new now Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com The serial issues on the serial collection page used to sort from new to old, which meant that the issues you were most likely to edit were at the top. Now the table sorts from old to new, which leaves the new items in a long list at the bottom. The old sorting should be restored. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 39620] New: Price not populating from 020$c when creating a basket
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39620 Bug ID: 39620 Summary: Price not populating from 020$c when creating a basket Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Have a MRC file with price populated in the 020$c 2. Have nothing the MarcFieldsToOrder or MarcItemFieldsToOrder sys prefs 3. Create a new basket and import from a new file 4. The price is not imported. My understanding is that if the price is set in the 020$c it should be copied over. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39991] New: Side By Side Record Comparision in Vendor File - Results No Longer Side by Side
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39991 Bug ID: 39991 Summary: Side By Side Record Comparision in Vendor File - Results No Longer Side by Side Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: brian.pichman(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the past the current record in Koha and the vendor record would be displayed side by side for comparison. Since the latest upgrade, they are now stacked, with the existing Koha record on top, and the vendor record below it. This means for every record we need to check, we have to scroll down to be sure the grid has been applied correctly. Steps to Reproduce The Problem: Receive a .mrc file from a library Stage and upload it through the cataloging module. In order to make sure the grid has been applied on the vendor side, view the record after staging the file. The results are now stacked. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 39534] New: Saved report subgroup filter not hidden correctly
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39534 Bug ID: 39534 Summary: Saved report subgroup filter not hidden correctly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org When viewing a tab on the saved reports page, a "subgroups" dropdown appears whether or not there are any subgroups for that group. The dropdown should be hidden if there are no subgroups. -- You are receiving this mail because: You are watching all bug changes.

1 16