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

[Bug 37440] New: Add option to never default to Cataloging Search
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37440 Bug ID: 37440 Summary: Add option to never default to Cataloging Search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Staff find the Cataloging Search interface unhelpful. It offers relatively little functionality that is not available in the default search interface and is broadly less familiar and therefore less desirable. While one is in the Cataloging module, the header defaults to Cataloging Search but also offers Search the Catalog. We'd love to have the option to make Search the Catalog the default with Cataloging Search available as an option should we ever want it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 43741] New: [Omnibus] Make Intranet header search customizable
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43741 Bug ID: 43741 Summary: [Omnibus] Make Intranet header search customizable Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This an omnibus bug for adding options for - What to show on the various search bars - Default selected option in the search bars -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36154] New: Add images to the lists and loan histories
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36154 Bug ID: 36154 Summary: Add images to the lists and loan histories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.le-gac(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Display images in lists and loan histories in both OPAC and the staff interface, similar to when conducting a search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 76

[Bug 43137] New: Add system health monitoring with status indicators in the staff interface header
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43137 Bug ID: 43137 Summary: Add system health monitoring with status indicators in the staff interface header 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha depends on several services (search engine, background job workers, SFTP endpoints) but provides no at-a-glance visibility into their health. Staff discover problems only when operations fail -- a patron search returns nothing, a batch job silently stops, or EDI transfers accumulate. Proposed solution: A system health framework that checks services, collects warnings and critical messages, and surfaces a summary indicator in the staff interface header. API response structure: GET /api/v1/health { "core": [ { "id": "search_engine", "label": "Search engine", "warnings": [ "Index koha_biblios last reindexed 3 days ago" ], "critical": [ "Elasticsearch cluster is red: 2 shards unassigned" ] }, { "id": "background_jobs", "label": "Background jobs", "warnings": [], "critical": [] }, { "id": "sftp", "label": "SFTP connections", "warnings": [ "EDI vendor X: connection timeout on last attempt" ], "critical": [] } ], "plugins": {} } - 'core' is an array of check results from Koha's own service checks - 'plugins' is a hash keyed by plugin class -- populated by companion bug (plugin hook) - Each check has 'warnings' and 'critical' arrays of human-readable messages - Empty arrays = healthy Header indicator logic: - Red: any 'critical' list is non-empty (core or plugins) - Yellow: any 'warnings' list is non-empty, no criticals - Green: all lists empty - Click navigates to detail view (new tab in about.pl System information, or standalone page) Core health checks to implement initially: - Search engine (Elasticsearch/Zebra): cluster/daemon reachability, index staleness - Background jobs: oldest pending job exceeds threshold (workers not picking up), failed jobs accumulating - SFTP connections: configured EDI/acquisition targets failing to connect Architecture: 1. Health check classes (Koha::Health::SearchEngine, Koha::Health::BackgroundJobs, Koha::Health::SFTP): - Each implements check() returning { id, label, warnings => [...], critical => [...] } - Checks must be cheap -- query local state only 2. API endpoint GET /api/v1/health: - Runs all core checks - Calls health_check plugin hook (see companion bug) - Caches the full assembled response (core + plugins) in Memcached with 30s TTL - A single cache key serves all users since health status is global - 60 terminals polling every 60s = ~1 req/s; with 30s cache only 2 actual check runs per minute - Permission-gated 3. Staff interface: - JS poller in header.inc, hits endpoint every 60s - Renders summary dot with tooltip showing count of warnings/criticals - Detail view groups checks by source (core section, then per-plugin sections) Display considerations: - Detail view could be a new tab on about.pl alongside existing system information - Or a standalone page -- either way, should render core and plugin sections grouped - Healthy checks still appear (as OK) so staff can see what is being monitored Caching: The endpoint caches the full assembled response in Memcached with a 30s TTL. A single cache key (koha:health) serves all users since health status is global -- not per-user or per-branch. 60 staff terminals polling every 60s means roughly 1 request per second on average. With a 30s cache, at most 2 actual health check runs happen per minute regardless of terminal count. Cache is TTL-based only -- no explicit invalidation needed since 30s staleness is acceptable for a status dot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 39944] New: Metadata should be trimmed before creating an ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39944 Bug ID: 39944 Summary: Metadata should be trimmed before creating an ILL request Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com When creating an ILL request, if the form data contains leading or trailing whitespaces, this may cause issues for backends. Example: A DOI is entered as ' 123', instead of '123'. If the backend needs to use that data entry, it'll need to first trim and/or sanitize it. It's better if core Koha does this trimming before delegating the creation of the request to the backend, so it's maintained in a single place. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 43570] New: Memory leark in SafeURL abd HtmlScrubber Template::Toolkit filters
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43570 Bug ID: 43570 Summary: Memory leark in SafeURL abd HtmlScrubber Template::Toolkit filters Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Right now every request that renders a page using SafeURL or HtmlScrubber leaks the entire template context. It seems to be around 7 to 13 MB per request depending on the page ( almost 8 MB on opac-detail, 11 on circulation.pl, and 13 on moremember.pl ). This memory doesn't get released at the end of the request because the context points to the filter, and the filter points to the context. The reason it hurts so much is what the context is. It's the root of the whole render. Every compiled template, the stash, and everything the stash was holding. On opac-detail.pl that's the Koha::Biblio, the MARC::Record and all the compiled templates. So one stuck context drags a whole page's worth of stuff along with it, and then we do it again on the next request, and the next. This is actually a known issue in TT 2.20+ and was done on purpose: # This causes problems: https://rt.cpan.org/Ticket/Display.html?id=46691 # If the plugin is loaded twice in different templates (one INCLUDEd into # another) then the filter gets garbage collected when the inner template # ends (at least, I think that's what's happening). So I'm going to take # the "suck it and see" approach, comment it out, and wait for someone to # complain that this module is leaking memory. # weaken($this); The call to weaken() was restored in TT 3.1, and they weaken _CONTEXT rather than the plugin itself, which is the same thing my patch will do. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 43737] New: Patron's Holds-tab doesn't show if a hold's status is "Processing"
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43737 Bug ID: 43737 Summary: Patron's Holds-tab doesn't show if a hold's status is "Processing" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: anni.maki-mantila(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In patron's Holds-tab there is a column "Status" that shows if the hold is waiting for pickup or being transferred. However there is also a third option for hold's status, "Processing" (found = 'P'). A hold gets this status when it's being returned via SIP and syspref "HoldsNeedProcessingSIP" is set to "Don't fulfill". It would be useful for staff to see this status as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40791] New: Allow choice of which Overdue messages can be patron preferences
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40791 Bug ID: 40791 Summary: Allow choice of which Overdue messages can be patron preferences Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In Bug 30515, we are discussing adding a new system preference UsePatronPreferencesForOverdueNotices to let patrons control which overdue messages are sent by mail in their messaging preferences. For many libraries it would still be necessary to set a certain overdue notice (say the third overdue notice) as "mandatory for print message". Jonathan suggested to reuse the aforementioned pref and make it multivaluated with 3 values possible: ODUE, ODUE2, ODUE3. Then: - if at least one is selected then patrons can edit it/them - if none selected, we don't allow the patrons to modify any This would be the simplest way to extend the functionality of Bug 30515. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43725] New: Add `--config-only` option to `koha-create`
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43725 Bug ID: 43725 Summary: Add `--config-only` option to `koha-create` Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Target Milestone: --- Working on the `koha-docker` project, I found the need for a way to get `koha-create` just initialize the configurations, but not start any services. While I understand the value of `koha-create` launching all the pieces, I believe it is mixing a lot of concerns, and we should have a way to limit its reach. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43735] New: Add Ability to Archive Baskets
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43735 Bug ID: 43735 Summary: Add Ability to Archive Baskets Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.petritsch(a)wienmuseum.at QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Hi, I would like to 'archive' or merge (into one) old basekts which are not only closed but not used at all anymore so that they only are visible if I select that in the basekt overview. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0