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

[Bug 42121] New: Allow hiding, filtering, or archiving of inactive courses for cleaner display
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42121 Bug ID: 42121 Summary: Allow hiding, filtering, or archiving of inactive courses for cleaner display Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library has a large number of courses that they store in Course Reserves, it is to their advantage to not delete inactive courses in case they reuse them in the future. Unfortunately, this also clutters up the display and makes it difficult to find active courses only. While the results can be sorted by using the "Enabled" column, searching by instructor etc. will still show both active and inactive courses. It would be helpful to have the ability to completely hide/filter inactive courses unless you choose to view them, similar to the "Include archived" checkbox for suggestion management. Another option could be allowing an "archiving" option for courses as a batch or individually, though this seems less user-friendly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37245] New: Add test script that runs `perl -c` on all Perl files
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37245 Bug ID: 37245 Summary: Add test script that runs `perl -c` on all Perl files Change sponsored?: --- Product: Koha Version: unspecified 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 Depends on: 35959 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35959 [Bug 35959] Inconsistent hierarchy during C3 merge of class 'Koha::AuthorisedValue' (and a few other modules) -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 42125] New: Add a script to run MARC Modification Templates from the command line
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42125 Bug ID: 42125 Summary: Add a script to run MARC Modification Templates from the command line Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Maybe I missed something, but I have not been able to find a script that can run a MARC Modification Template (MMT) on records from the command line. Currently it seems you have to feed the "Batch record modification" tool a list or file of biblionumbers in order to apply an MMT to a lot of records, and this has limitations in terms of how many biblionumbers you can supply at once. It would be better to do this with a script, preferrably with a --where option, to limit which records to run the script on, similar to how other scripts work. Not sure if it would make sense to extend misc/maintenance/touch_all_biblios.pl with this functionality, or if it would make sense to have it as a separate/new script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42124] New: Cypress not starting on Trixie
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42124 Bug ID: 42124 Summary: Cypress not starting on Trixie Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major 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 We certainly need to update Cypress, we use an outdated version (12.17.4) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 27434] New: Task Scheduler should use classes as job types
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27434 Bug ID: 27434 Summary: Task Scheduler should use classes as job types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Task Scheduler Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Rather than maintaining a list of types and going through each case we should use the class as the job type so we can call it directly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42120] New: Note in SIP Account setup that Institution determines logged-in library
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42120 Bug ID: 42120 Summary: Note in SIP Account setup that Institution determines logged-in library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 37893 In the new SIP interface, it would be helpful to have a tooltip or other note in the account setup page to clarify that the institution set for an account will determine which library that SIP account's circ actions are tied to. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 [Bug 37893] Migrate some SIP configuration into the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38080] New: Sorting options for holdings table are incorrect
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38080 Bug ID: 38080 Summary: Sorting options for holdings table are incorrect Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The sorting seems to rely on the correct ordering of the columns from the DB/YAML - the current order does not match the displayed order, so if you select to sort by CCODE, we actually sort by callnumber -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40988] New: Subfunds in acqui-home.pl and aqbudgets.pl are not collapsable beyond 20th line
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40988 Bug ID: 40988 Summary: Subfunds in acqui-home.pl and aqbudgets.pl are not collapsable beyond 20th line 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When Koha renders the table of funds and subfunds for the acq homepage and the funds page in Administration, it inserts a little triangle button next to each parent fund that can be used to collapse the associated sub-funds. However, it only inserts these little buttons for parent funds within the first 20 funds returned. Beyond the 20th fund, all funds & subfunds and listed correctly but the triangle button isn't offered and subfunds cannot be collapsed. This page defaults to 20 entries per page and it looks like we're only inserting collapse buttons for what's shown at page load. If one adjusts the table to show only 10 entries, the 11th-20th parent funds will still show their collapse button successfully, but changing the number of entries to show doesn't reload the page. To recreate: - Have 20 funds, no subfunds - Add a subfund to the first fund in your list - see that the parent fund has a little triangle you can use to collapse its subfund - note that this has pushed the last fund in your list onto a second page - add a subfund to the last fund in your list - confirm this parent fund on does *not* get a little triangle button and you cannot collapse it -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 40625] New: Cashup re-submissions on page reload
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40625 Bug ID: 40625 Summary: Cashup re-submissions on page reload Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk The point of sale Cashup submission should use post/redirect/get pattern. We have been seeing duplicate cashup records and have identified that it's after an initial cashup has been performed and the user has left the page open. When they return, they reload the page (or Chrome auto-reloads it) and it performs the post again causing an empty or unexpected cashup to be recorded. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40915] New: SIP message parsing with empty fields not perfect
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40915 Bug ID: 40915 Summary: SIP message parsing with empty fields not perfect Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org SIP message parsing can create empty field values that later cause DBIx::Class constraint errors when passed to Koha operations. The current parsing logic in C4::SIP::Sip::MsgType::_initialize() doesn't provide debug logging to help identify when critical fields (patron_id, item_id) are empty, making it difficult to troubleshoot "Odd number of elements in anonymous hash" errors in SIP server logs. This includes some scenarios which cause fields to be treated as (empty) arrayrefs, which flood the logs with this kind of errors: ``` DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'itemnumber' at /usr/share/koha/lib/Koha/Objects.pm line 95 DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'borrowernumber' at /kohadevbox/koha/Koha/Objects.pm line 95 ``` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21