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

[Bug 41386] New: Adding 0.00 as value for "Expired hold charge" in circulation rules can lead to exception Koha::Exceptions::Account::AmountNotPositive
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41386 Bug ID: 41386 Summary: Adding 0.00 as value for "Expired hold charge" in circulation rules can lead to exception Koha::Exceptions::Account::AmountNotPositive Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org If one adds 0.00 as "Expired hold charge" rules value in circulation rules and charge is then tried to add to a patron via Koha::Account->add_debit, exception Koha::Exceptions::Account::AmountNotPositive is raised. This can be really confusing for the users since monetary values in circulation rules typically allow using decimal values in them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 43146] New: Add Koha::Health::SFTP health check
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43146 Bug ID: 43146 Summary: Add Koha::Health::SFTP health check 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 Depends on: 43137 Target Milestone: --- Follow-up to Bug 43137 (system health monitoring framework). Adds a Koha::Health::SFTP class that checks the reachability of configured SFTP transport endpoints (used by EDI/acquisitions). Alert codes: - sftp_unreachable: { code => 'sftp_unreachable', params => { host => 'hostname', error => '...' } } Permission: { acquisition => 'edi_manage' } The check iterates Koha::File::Transport::SFTPs and attempts a connection test on each configured endpoint. Results should be cached appropriately since SFTP connections are expensive. Considerations: - Only check endpoints that are actively in use (have recent activity) - Connection timeout should be short (e.g., 5 seconds) to avoid blocking - Report each failing endpoint as a separate warning/critical entry Should include full test coverage (mocked, not DB-dependent). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43137 [Bug 43137] Add system health monitoring with status indicators in the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 43138] New: Add health_check plugin hook for publishing alerts to the system health framework
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43138 Bug ID: 43138 Summary: Add health_check plugin hook for publishing alerts to the system health framework Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 43137 Target Milestone: --- Companion to Bug 43137 (system health monitoring). Plugins that manage external service connections need a way to publish their warnings and critical alerts through the same health framework, grouped by plugin. How it works: Core calls the hook, wraps the result with the plugin's metadata, and keys it by class in the 'plugins' hash of the /api/v1/health response. Plugin hook contract: sub health_check { my ($self) = @_; return { url => '/cgi-bin/koha/plugins/run.pl?...&page=status', # optional drill-down link checks => [ { id => 'pod_dev03', label => 'Pod dev03-na', warnings => ['3 tasks in retry state for over 1 hour'], critical => ['HTTP 500 -- task queue delayed until 15:19 (100 tasks affected)'], }, { id => 'pod_prod', label => 'Pod prod-eu', warnings => [], critical => [], }, ], }; } Core assembles the response: { "core": [ ... ], "plugins": { "Koha::Plugin::Com::ByWaterSolutions::RapidoILL": { "name": "Rapido ILL", "url": "/cgi-bin/koha/plugins/run.pl?...&page=status", "checks": [ { "id": "pod_dev03", "label": "Pod dev03-na", "warnings": ["3 tasks in retry state for over 1 hour"], "critical": ["HTTP 500 -- task queue delayed until 15:19 (100 tasks affected)"] }, { "id": "pod_prod", "label": "Pod prod-eu", "warnings": [], "critical": [] } ] } } } - 'name' is derived automatically from the plugin's metadata ($plugin->get_metadata->{name}) - 'url' is optional -- if provided, the detail view links the plugin heading to its own status page - The plugin class is used as the hash key -- stable, unique, no collisions Requirements for plugin authors: - The hook MUST be cheap (local DB queries only, no external HTTP calls) - Return one or more checks (e.g., one per configured endpoint/pod/service) - Empty 'warnings'/'critical' arrays = healthy (still shows OK in the detail view under the plugin group) - Return undef to not participate at all Fault isolation: - Each plugin's health_check call is wrapped in try/catch - A failing hook produces: { name => $plugin_name, checks => [{ id => 'error', label => $plugin_name, warnings => [], critical => ["Health check failed: $error"] }] } - Other sources are unaffected Header indicator logic includes plugin alerts: - Plugin criticals turn the dot red - Plugin warnings turn the dot yellow (if no criticals anywhere) - A broken plugin hook counts as a critical (the framework itself is unhealthy) Use cases: - Rapido ILL: critical when 5xx errors delay the task queue, warning when tasks are stuck in retry - NCIP relay: warning when response times exceed threshold - SIP2 connector: critical when connection pool is exhausted - Discovery sync: warning when last successful sync exceeds configured interval Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43137 [Bug 43137] Add system health monitoring with status indicators in the staff interface header -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 13985] [Omnibus] Cash Management - Koha as 'Point of Sale'
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 Bug 13985 depends on bug 41705, which changed state. Bug 41705 Summary: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41124] New: Add search options for moving hold to new biblio record
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41124 Bug ID: 41124 Summary: Add search options for moving hold to new biblio record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 31698 Currently moving a hold to a new biblio record requires the user to enter the biblionumber of the new record. It would be helpful if a search for the new target bib could be incorporated into the workflow to move the hold. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31698 [Bug 31698] Add ability to move a hold to a new bibliographic record/item -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 19557] New: Saved Filters from Advanced Search in OPAC
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19557 Bug ID: 19557 Summary: Saved Filters from Advanced Search in OPAC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a patron performs an advanced search on the OPAC, the filters (that they selected on the advanced search page) will not save if the patron searches then edits the search box on the results page. Steps 1) Click on the advanced search link 2) Search for keyword or title in your collection 3) Your brief results page populates 4) This will give you a breadcrumb trail of your advanced search (RESULTS OF SEARCH FOR 'KW,WRDL: FLORIDA NOT KW,WRDL: TRAVEL' 5) select a facet on the left to filter your results 6) now search in the search box on cgi-bin/koha/opac-search.pl While Koha treats this as a new search, it would be great to have an option for the patron to modify that original advanced search -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 43132] New: Whitespace remov
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43132 Bug ID: 43132 Summary: Whitespace remov Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: infoscienceaddict(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- While cataloging (either in bibliographic or authority records), a common mistake is the addition of extra whitespace characters at the begining or end of fields and/or subfields. This has a huge impact, especially in report results exported as csv, as the values of fields are shifted to the next column whenever a whitespace character is to be found at the beginning or the end of the field/subfield. It would be great if all whitespace characters where to be removed from free text fields (not from Control Fields). In order to make it a universal feature (in case some users need these whitespace characters), a yes/no warning message for whitespace character deletion may be a better feature? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43147] New: Allow a match point to require two independent fields to both match (e.g. 001 and 003)
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43147 Bug ID: 43147 Summary: Allow a match point to require two independent fields to both match (e.g. 001 and 003) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- C4::Matcher's match points cannot express "these two independent fields must both match" as a single condition. This makes it impossible to configure a record matching rule that treats a MARC control number (001) as authoritative only in combination with its control number identifier (003), which is a common and useful matching strategy for imported records from external sources that reuse 001 values across different originating systems. Currently, adding multiple components to one match point concatenates their extracted values into a single search phrase (see _get_match_keys in C4/Matcher.pm), rather than requiring each component to match independently. This doesn't produce AND semantics even in principle, because the underlying search indexes for 001 (control-number) and 003 (control-number-identifier) are indexed as completely separate fields (see admin/searchengine/elasticsearch/mappings.yaml). A concatenated phrase search against either index alone can never correctly require both fields to match, since neither index contains both values together. Request: add a way to define a match point (or a new kind of match point) that requires two or more independent search index values to each be present on the same candidate record, rather than concatenating them into one phrase search. This would let a matching rule express "match only if 001 matches AND 003 matches", analogous to how Koha already supports "required checks" at the matcher level, but scoped to build a single match point's own pass/fail condition from multiple independently-matched fields. Test plan: 1. Create two bibliographic records where record A has 001 = "12345", 003 = "OSt", and record B has 001 = "12345", 003 = "DLC". 2. Create a record matching rule with a single match point on the control-number index (tag 001) plus a second component for the control-number-identifier index (tag 003). 3. Stage an incoming record with 001 = "12345", 003 = "DLC" for import. 4. Observe that Koha's matcher cannot be configured to match only record B (matching both 001 and 003) while correctly excluding record A (which only shares 001) -- either both records score as candidates, or neither does, because there's no way to require both fields to agree for the same candidate as a single condition. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43144] New: Allow Elastic searches to fall back to fuzzy search when zero results
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43144 Bug ID: 43144 Summary: Allow Elastic searches to fall back to fuzzy search when zero results Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When a catalog search using Elastic returns zero results on a non-fuzzy search, it would be nice to have the option for Koha to automatically repeat the search as fuzzy, with a clear indication on the results page of what has happened. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 20481] New: Subscriptions with multiple late issues do not properly convert to makePreviousSerialAvailable status when the late issues are brought in
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20481 Bug ID: 20481 Summary: Subscriptions with multiple late issues do not properly convert to makePreviousSerialAvailable status when the late issues are brought in Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When a library is using the system preference makePreviousSerialAvailable it allows them to make a previous serial automatically available when receiving a new serial issue. However if there are multiple serials marked late in the subscription, the system preference makePreviousSerialAvailable does not automatically change when the next item is brought in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4