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

[Bug 41418] New: Add spell check to search
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41418 Bug ID: 41418 Summary: Add spell check to search Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org A 'did you mean' feature or some kind of spell check options would be helpful, especially for users with intellectual disabilities -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35066] New: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35066 Bug ID: 35066 Summary: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For libraries using the holds queue, they should have the ability to deny filling the hold so it would push the item onto the next branch's holds queue without having to wait for the cron to run. Right now, the only way to move an item off a library's queue is to mark it as missing/lost or damaged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 41749] New: Add patron consent status display to staff patron detail page
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41749 Bug ID: 41749 Summary: Add patron consent status display to staff patron detail page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Depends on: 31503 Currently, staff members have no visibility into what consents a patron has given or refused. The consent management exists only in the OPAC (opac-patron-consent.pl), where patrons can manage their own consent preferences for GDPR and plugin-defined consent types (added in bug 31503). This creates a gap in staff workflows - when assisting patrons or reviewing accounts, staff cannot see whether a patron has consented to privacy policies or other consent types defined by plugins. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31503 [Bug 31503] Allow several consent types on the consents tab of OPAC account page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 36930] New: Item search gives irrelevant results when using 2+ added filter criteria
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36930 Bug ID: 36930 Summary: Item search gives irrelevant results when using 2+ added filter criteria Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the Item search a librarian is allowed, in the first step, to define additional filters like Title, Author, Publisher, Publication date etc. (the third fieldset). This works fine but only for one criterion. If one adds two or more criteria, the filter does not apply at all. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 36164] New: Bring more consistency to our module landing pages
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36164 Bug ID: 36164 Summary: Bring more consistency to our module landing pages 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 Koha's modules have a variety of landing page designs. We should try to move to a more consistent approach across landing pages. This bug serves as a collector for such work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42036] New: Add diff support to REPORTS action logs
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42036 Bug ID: 42036 Summary: Add diff support to REPORTS 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 for saved reports does not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Currently log entries store the report name and SQL concatenated as a plain string. Affected calls: - reports/guided_reports.pl MODIFY (~line 250): logaction( "REPORTS", "MODIFY", $id, "$reportname | $sql" ) (no $original; only post-change state captured as a string) - reports/guided_reports.pl ADD (~line 594): logaction( "REPORTS", "ADD", $id, "$name | $sql" ) - C4/Reports/Guided.pm DELETE (~line 798): logaction( "REPORTS", "DELETE", $id, $data->report_name . " | " . $data->savedsql ) This bug covers updating these calls to pass structured hashrefs (e.g. { report_name => ..., savedsql => ... }) as $infos and, for MODIFY, the pre-change report data as $original, enabling proper before/after diff display in the action log viewer. 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 17

[Bug 38270] New: Add MARCXML options to ElasticsearchMARCFormat
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38270 Bug ID: 38270 Summary: Add MARCXML options to ElasticsearchMARCFormat Change sponsored?: --- Product: Koha Version: Main 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As noted on bug 27365, Elasticsearch search results don't get fetched correctly if a MARCXML record cannot be serialized in the compact ISO MARC 2709 format. One reason it might not be able to be serialized is due to 1 MARC field containing more than 9999 bytes or a whole record containing more than 99999 bytes. The change to be provided here will store MARCXML instead of ISO MARC 2709. -- During development, it may be found that a compressed form of MARCXML is preferred to an uncompressed form to be more comparable with the currently stored ISO MARC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 27365] New: Koha doesn't check marcxml field size is < 10000 and fails in various places
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27365 Bug ID: 27365 Summary: Koha doesn't check marcxml field size is < 10000 and fails in various places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi ISO standard >The core of the framework is a MARCXML schema that allows lossless round-trip >conversion of an ISO 2709 MARC 21 record and an XML-encoded MARC 21 record. Thus a field size is 9999 bytes max. But /usr/share/perl5/MARC/File/USMARC.pm doesn't care: my $direntry = sprintf( "%03s%04d%05d", $field->tag, $len, $dataend ); and if len >= 10000 it silently creates a bogus directory with a length of 13 rather then 12. These non-conformed marxml will fail in various places. Export, search results list with elasticsearch which store ISO 2709 record in index and use them as data source in results list. eg: Easy to trigger in french UNIMARC with 359 (sorry in french) https://www.transition-bibliographique.fr/wp-content/uploads/2019/02/B359-2… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 40960] New: Notifying holds should not print notice if no messaging preference is notified
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960 Bug ID: 40960 Summary: Notifying holds should not print notice if no messaging preference is notified Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In overdue_notice.pl, holds_reminder.pl, no paper notice is sent to patron if no checkbox is checked. This should be the same for notifying holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35