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

[Bug 42835] New: ElasticSearch should have an items index
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 Bug ID: 42835 Summary: ElasticSearch should have an items index Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 130

[Bug 43884] New: queue_notice does not fall back to print when itiva cannot deliver
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43884 Bug ID: 43884 Summary: queue_notice does not fall back to print when itiva cannot deliver Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices 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 Depends on: 43380 Target Milestone: --- Bug 43380 made C4::Reserves::_koha_notify_reserve fall back to a print notice when itiva cannot deliver the notice, that is when TalkingTechItivaPhoneNotification is disabled or the patron has no phone number. Koha::Patron::queue_notice still has 'next if $mtt eq itiva && TalkingTechItivaPhoneNotification' with no phone check, so in those cases the notice is silently dropped. This affects overdue, preoverdue and the other notices that go through queue_notice. This bug aligns queue_notice with the hold-filled behaviour and adds tests. Additionally, TalkingTech_itiva_outbound.pl selects rows on the itiva preference only, so patrons with no phone number get a row with a blank phone in the CSV. It should skip rows with an empty borrowers.phone. Test plan: 1. Set TalkingTechItivaPhoneNotification to Enable. 2. Give a patron an overdue notice preference of itiva only, with a phone number set. 3. Trigger the notice (e.g. run overdue_notices.pl) and note no print notice is queued. 4. Clear the patron's phone number and repeat. 5. Note a print notice is queued. 6. Disable TalkingTechItivaPhoneNotification, restore the phone number and repeat. 7. Note a print notice is queued. 8. Run TalkingTech_itiva_outbound.pl and note that rows with no phone number are not output. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43380 [Bug 43380] Koha will generate spurious print notices if itiva is enabled and a patron has only selected phone notices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27248] New: Allow to use list of barcodes/itemnumbers with Batch extend due dates tool
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27248 Bug ID: 27248 Summary: Allow to use list of barcodes/itemnumbers with Batch extend due dates tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In some cases libraries want to use some more complicated criteria for selecting the items that they want to extend the due dates for. For these cases it would be great if SQL reports could be used to make a list that then can be uploaded to the tool, similar to how we manage other batch operations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 42108] New: Add ability to specify that a report can only be run as a foreground or background report
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 Bug ID: 42108 Summary: Add ability to specify that a report can only be run as a foreground or background report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Building on bug 41921, it would be useful to be able to specify a report can only run as a background report for long-running reports. For the sake of completeness, we could also add the ability to specify reports as being foreground-only reports as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 42627] New: Printing a range of barcodes should be from and quantity instead of from and to
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42627 Bug ID: 42627 Summary: Printing a range of barcodes should be from and quantity instead of from and to Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When printing a barcode range we should have "From" and "Number of barcodes to print" instead of "From" and "To". This way the user could enter the starting barcode and the number to print from there. This is because, like David says in Bug 41162, calculating the difference between from and to is hard. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162#c1 "Number of barcodes to print" could then have a limit, say 1000 which seems fair, and then we just exit the loop after that number. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 32328] New: Add ability to specify how long an item stays on a library's holds queue
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32328 Bug ID: 32328 Summary: Add ability to specify how long an item stays on a library's holds queue Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With multi-location libraries that are open varying hours, it would be helpful to be able to specify how long an item appears on a library's hold queue before the item appears on another location's queue. For example, Title A is available at both Library D and Library E. The patron wants to pickup the item at Library D. Library D is closed Saturday and Sunday, but Library E is not. Currently, the item could potentially show on Library E's hold queue. Since it takes three days of transit time to move the item from Library E to Library D, it would be faster to fill the hold from Library D, but because it was moved off Library D's queue, it won't be filled there. It would be nice to be able to specify by Library how long an item will appear on the holds queue for that library before it is moved, and the item is sent from another library. Using Holds Queue Skip Closed (and the other associated sys prefs) does not address this sufficiently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41921] New: Add ability to run reports as background jobs
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41921 Bug ID: 41921 Summary: Add ability to run reports as background jobs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com It would be nice if reports can as background jobs instead of standard page loads. This would allow long running reports to be viewable from the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 269

[Bug 43606] New: Add x-koha-embed: items support to GET /biblios (list), respecting OPAC/public item visibility
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43606 Bug ID: 43606 Summary: Add x-koha-embed: items support to GET /biblios (list), respecting OPAC/public item visibility Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- The REST API endpoint GET /biblios (operationId listBiblio) can return records as MARCXML, MARC-in-JSON, USMARC and plain text via content negotiation. However, the serialized records never include item data (952 fields), even when the caller would like them embedded. Currently: * The swagger definition for GET /biblios (api/v1/swagger/paths/biblios.yaml) does not declare an x-koha-embed header parameter. Because OpenAPI input validation is strict, sending "x-koha-embed: items" against this endpoint results in an HTTP 400 response. * The controller Koha::REST::V1::Biblios::list serializes with $biblios->print_collection('marcxml'), passing no embed option. * Koha::Objects::Record::Collections::print_collection has a positional signature ( $self, $format ) and serializes each element using $element->record, i.e. the raw stored MARC with no items. As a result, clients that need biblios with items must fall back to fetching items one biblio at a time (GET /biblios/{biblio_id}/items), which is an N+1 access pattern and is significantly slower for bulk/list use cases. Proposed enhancement: Add the ability to embed items into the records returned by the list endpoints, driven by the existing x-koha-embed request header, e.g.: x-koha-embed: items Item visibility MUST be respected according to the interface the request is served on: * Staff/intranet route (GET /biblios): embed all items (subject to the existing catalogue permission already required by the endpoint). * Public route (GET /public/biblios and related public list endpoints): embed only items visible in the OPAC, honouring OpacHiddenItems and patron category override_hidden_items, consistent with how get_public, get_items_public and Items::list_public already scope items via filter_by_visible_in_opac. The building block already exists: Koha::Biblio::metadata_record already supports: $biblio->metadata_record({ embed_items => 1, interface => 'opac' | 'intranet', patron => $patron, }); which applies the EmbedItems record processor and, for the opac interface, scopes items through filter_by_visible_in_opac (plus the ViewPolicy filter). Suggested implementation outline: 1. Give print_collection a hashref-based signature that accepts embed_items (and interface/patron), choosing per element between $element->record and $element->metadata_record({ embed_items => 1, interface => ..., patron => ... }). 2. In the list controllers, read the embed list from the request (the koha.embed stash populated when x-koha-embed is sent) and pass embed_items through to print_collection. The public list controller must pass interface => 'opac' and the current patron so OPAC visibility rules apply; the staff controller passes interface => 'intranet'. 3. Declare the x-koha-embed header parameter with an "items" enum value on the listBiblio operation (and the equivalent public list operation) in the swagger spec, so the header is accepted instead of rejected with HTTP 400. This keeps serialization logic in the collection class, reuses the existing item-visibility scoping, and makes it possible to retrieve a page of biblios with their items in a single request rather than one request per record. Backwards compatibility: default behaviour (no x-koha-embed header) is unchanged and continues to return records without items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43882] New: Allow multiselect for library limitations on additional contents
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43882 Bug ID: 43882 Summary: Allow multiselect for library limitations on additional contents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When creating custom pages or other additional contents (html customizations, news, etc), it would be helpful to be able to limit to multiple libraries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43663] New: Add Koha::Objects::Mixin::Polymorphic for polymorphic subclass dispatch
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43663 Bug ID: 43663 Summary: Add Koha::Objects::Mixin::Polymorphic for polymorphic subclass dispatch Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Several Koha::Objects plural classes independently implement the same pattern: given a row, decide which Koha::Object subclass should represent it, based on the value of one column (a hand-rolled _polymorphic_field/_polymorphic_map pair plus an ~8-line object_class method). Koha::File::Transports (already in main) dispatches on the 'transport' column to Koha::File::Transport::{SFTP,FTP,Local}. Koha::Auth::Identity::Providers (bug 24880, not yet merged) dispatches on 'protocol' to Koha::Auth::Identity::Provider::{OAuth,OIDC,SAML2}. The same need came up again during review of bug 42870 (pluggable email transports). Koha::Auth::Identity::Provider::OAuth additionally hand-types its own dispatch key a second time, independently, inside its own new() ($params->{protocol} = 'OAuth';) - nothing ties that string to the _polymorphic_map entry in the plural class that has to match it, so the two can silently drift apart. This bug extracts the shared behaviour into a proper Koha::Objects::Mixin::* (the same convention Koha already uses for Koha::Objects::Mixin::AdditionalFields, composed via 'use parent qw( Koha::Objects Koha::Objects::Mixin::Foo )', used by 20+ plural classes), and migrates the one already-in-main consumer (Koha::File::Transports) onto it as proof it is behaviour-preserving. A consuming plural class declares: sub _polymorphic_field { return 'transport' } sub _polymorphic_classes { return (List::Of::Class::Names) } sub _polymorphic_base_class { return 'Fallback::Class::Name' } Each subclass self-declares its own dispatch key: sub _polymorphic_key { return 'sftp' } The mixin builds _polymorphic_map from _polymorphic_classes plus each class's own _polymorphic_key, and provides object_class() itself, so the copy-pasted dispatch logic disappears from every consumer, not just the map. A plural class needing genuinely custom mapping logic can still override _polymorphic_map (or object_class) directly - ordinary Perl inheritance makes that a free escape hatch. This is a proposal filed ahead of code, based on a design worked out with the QA team. It is deliberately narrow: it introduces no mechanism for Koha Plugins to register additional polymorphic subclasses, no Plugin management UI changes, and no koha-conf.xml changes - that is a separate, later concern once a concrete capability needs it. It does not touch Koha::Auth::Identity::Providers (bug 24880) or bug 42870 directly; both could adopt this mixin as a follow-up once merged. Patches to follow. Test plan (once patches are attached): 1. Apply the patch(es). 2. Run prove t/db_dependent/Koha/Objects/Mixin/Polymorphic.t and confirm all tests pass. 3. Run prove t/db_dependent/Koha/File/Transport.t t/db_dependent/Koha/File/Transports.t t/db_dependent/Koha/File/Transport/FTP.t t/db_dependent/Koha/File/Transport/Local.t t/db_dependent/Koha/File/Transport/SFTP.t and confirm they all still pass unmodified against the migrated Koha::File::Transports, proving the migration is behaviour-preserving. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16