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

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 42814] New: Advance notice checkboxes enabled in inactive messaging preferences form
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42814 Bug ID: 42814 Summary: Advance notice checkboxes enabled in inactive messaging preferences form Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 28308 added JavaScript to disable the Advance notice transport checkboxes when "Days in advance" is blank. However, the JavaScript only checks the value of the days select. When the messaging preferences form is inactive/read-only and a non-blank days value is selected, the script removes the disabled state from the checkboxes. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 42605] New: Acquisition Items not listed during receipt
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 Bug ID: 42605 Summary: Acquisition Items not listed during receipt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Ensure AcqCreateItem is set to 'placing an order' at syspref or on basket 2 - Open a basket, add an order, and add several items 3 - Close the basket and receive shipments 4 - Select the order and 'Receive selected' or click 'Receive' on the order 5 - No items are listed in the items section -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 42764] New: codespell.t fails after container OS upgrade due to newer codespell dictionary
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42764 Bug ID: 42764 Summary: codespell.t fails after container OS upgrade due to newer codespell dictionary Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org When the KTD container OS is upgraded (e.g. Debian Bookworm -> Trixie), two things happen simultaneously that cause xt/author/codespell.t to fail: 1. The OS codename changes, so Koha::Devel::CI::IncrementalRuns finds no history in the ci-results repository for the new codename and falls back to a full scan of all tracked files. 2. The newer OS ships a newer codespell version (installed unversioned from apt in package-config.yaml). Each codespell release expands its misspelling dictionary, so words silently accepted by the old version are now flagged. The combination means the first full scan on a new container OS fails on pre-existing code that was never touched since the old codespell version accepted it. The .codespell-ignore file (currently 20 entries) was developed against older codespell versions and does not cover terms newly flagged by the upgraded version. Test plan: 1. Apply patch 2. Run xt/author/codespell.t inside the new KTD container => All tests pass -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42592] New: Flag +count embeds that cannot be sorted
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42592 Bug ID: 42592 Summary: Flag +count embeds that cannot be sorted 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: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 41950 After bug 41950, +count embeds backed by a DBIC relationship are automatically sortable. However, some +count embeds are only computed at the Perl level (no matching DBIC relationship) and cannot be sorted. Currently, consumers discover this only by receiving a 400 error when attempting to sort. We need a mechanism to flag or advertise which +count embeds are sortable and which are not. This could be: 1. An annotation in the OpenAPI spec (e.g. x-sortable: false on the embed enum value) 2. A response header listing sortable fields 3. Documentation in the API markdown 4. A dedicated endpoint or metadata response The goal is to let API consumers know upfront which +count columns support sorting, without trial and error. Discussion started in bug 41950 comment 17. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 41265] New: NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees circulation checks not precise enough
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41265 Bug ID: 41265 Summary: NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees circulation checks not precise enough Initiative type: --- Sponsorship --- status: 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Hello all When a checkout is performed, the NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees values are checked. This is an ‘if’ statement with check values, but by default, these are empty strings and therefore defined in this way. I therefore believe that the verification is not exactly what we want, particularly when SIP performs the checkout without permission to force it. Furthermore, in kohastructure, the default value would be NULL from what I understand, and it has not been included in the syprefs sql file. Perhaps there are some cases that I am overlooking, but I will suggest a simple fix anyway. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 41404] New: No need to check related guarantor/guarantee charges when the limits are not set
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41404 Bug ID: 41404 Summary: No need to check related guarantor/guarantee charges when the limits are not set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the code: # Check the debt of this patrons guarantees if ( defined $no_issues_charge_guarantees ) { # Check the debt of this patrons guarantors *and* the guarantees of those guarantors if ( defined $no_issues_charge_guarantors_with_guarantees ) { It is not possible to undef the system preferences, they are set as blank for no value - we need to check if they are numbers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 39419] New: Holds API treats 'expiration_date' as 'patron_expiration_date'
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39419 Bug ID: 39419 Summary: Holds API treats 'expiration_date' as 'patron_expiration_date' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 This is going to have a related issue in Aspen, but I think the confusion starts here Koha has two fields for hold expiration: expirationdate - (usually) auto generated date set based no when holds on the shelf expire patron_exiration_date - the day the patron says they don't need the hold after The API takes "expiration_date" and maps it to "patron_expiration_date" This can be unclear for outside systems. Aspen has a 'Default Not Needed After Days' setting which is assumed to be setting the automatic expiraton date, but in fact sets the patron date We should allow either field to be set via the API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[Bug 42879] New: Avoid per-record plugin lookup in ES marc_records_to_documents
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42879 Bug ID: 42879 Summary: Avoid per-record plugin lookup in ES marc_records_to_documents 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- marc_records_to_documents invokes Koha::Plugins->call('elasticsearch_to_document', ...) once per record. Each call discovers the plugins implementing the hook, which runs a query against plugin_data -- even when no plugin implements the hook or plugins are disabled. In a batch reindex this is one extra query per record purely to discover there is nothing to call. The set of implementing plugins is constant for the batch. Resolve it once (or short-circuit when plugins are disabled / none implement the hook), then dispatch per record. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. With a plugin implementing elasticsearch_to_document, confirm the hook still fires for every record. 3. Count DB statements during a batch reindex before/after. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6