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

[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

[Bug 42123] New: Add UI to test configuration sources against example call numbers
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42123 Bug ID: 42123 Summary: Add UI to test configuration sources against example call numbers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I was testing out the awesome bug 41932 and I realised it would be good to be able to visualise what a call number looks like when a filing rule or splitting rule is applied to it. For bug 41932 I'm doing it as a developer by writing unit tests, but it would be so handy for libraries and for people providing support to be able to just check a call number against a classification source in the web UI. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 8292] clicking ignore on hold cancels transfer
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '26

17 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8292 trevor.diamond(a)mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond(a)mainlib.org --- Comment #18 from trevor.diamond(a)mainlib.org --- We've been on Koha only since 2025, but this would be great if it could be fixed. Clicking ignore should either initiate a transfer modal or perhaps change the button to say "ignore hold and transfer item home" or something. While you can send the item without electronically tracking the transfer in Koha, this ends up with annoyed patrons who think an item is available when it's not and that same item might show up on the holds queue and staff might end up wasting time looking for an item that's on the delivery truck. -- You are receiving this mail because: You are watching all bug changes.

1 0