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

[Bug 43252] New: Give transport cost matrix a shortcut to autofill based on distances between libraries
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43252 Bug ID: 43252 Summary: Give transport cost matrix a shortcut to autofill based on distances between libraries Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- If branches have their addresses in the branch (library) setup, it seems like it might be reasonably easy to have Koha calculate distances between branches and auto fill the matrix with these distances at the push of a button, if the admin is basing the cost on distance. It would definitely make for a quick setup or default. I can see this being added to the Populate empty cells button. It would also be helpful to add a Clear all cells button and the option to override existing settings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43251] New: Preference to delete a biblio if there are no item but linked to an order
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43251 Bug ID: 43251 Summary: Preference to delete a biblio if there are no item but linked to an order 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently, if you have a biblio with no items and try to delete it, if it is linked to an order it will give you a warning and allow you to delete it only if you have acquisition permissions. Some libraries have a workflow where if something is on order, it will also have an item in the record, and likely to have an on order status. Therefore, it would be reasonable to allow catalogers that don't have acquisition permissions to delete this item. We should either have a permission in cataloging that would allow the deletion of biblios tied to an order if there are no items in the record, or there should be an acquisitions preference that would allow this behavior. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34705] New: Koha should use a CSV library to generate CSV
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34705 Bug ID: 34705 Summary: Koha should use a CSV library to generate CSV Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Generating CSV using a template and concatenating string using separators doesn't always generate valid CSV, and should be a avoided. The Koha codebase shouldn't contain code to deal with special escape sequences or CSV generation internals. We already include Text::CSV_XS and should just pass it arrayrefs for each row, and let the library deal with CSV complexities [1]. This was highlighted by bug 34043. [1] https://en.wikipedia.org/wiki/Comma-separated_values#Basic_rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38330] New: Make bib-level suppression a biblio table field instead of part of a marc tag
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38330 Bug ID: 38330 Summary: Make bib-level suppression a biblio table field instead of part of a marc tag Change sponsored?: --- 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: danielle.elder(a)law.utexas.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Suppression should be a biblio table field instead of in a marc field. Running reports with it to extract that field each time is not optimal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 43250] New: Library float limits feature should have its own permission
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43250 Bug ID: 43250 Summary: Library float limits feature should have its own permission Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 28530 Target Milestone: --- Currently, the new Library float limits feature (Bug 28530) is controlled by the 'Manage library transfer limits and transport cost matrix (manage_transfers)' permission under the 'parameters' umbrella. It would be helpful to have it be a separate permission for libraries who want specific staff to have access to item type float limits without other granting access to other transfer settings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28530 [Bug 28530] Allow configuration of floating limits by item type -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 26282] New: Allow staff to decide if a hold cancellation notice will be sent when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26282 Bug ID: 26282 Summary: Allow staff to decide if a hold cancellation notice will be sent when cancelling a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 25534 Bug 25534 adds the option to send hold cancellation notices when a reason was given. It would be nice if you could give a reason but still decide not to send to the patron. Say the patron called and will not be able to pick up numerous holds for some time. You cancel them all with "patron requested cancellation" but don't want to send multiple notices. I could imagine a checkbox next to the reason to activate/deactivate sending the notice. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25534 [Bug 25534] Add ability to send an email specifying a reason and store the reason when canceling a hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 171

[Bug 28530] New: Allow configuration of floating limits by item type
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28530 Bug ID: 28530 Summary: Allow configuration of floating limits by item type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com When return policy is set to Item Floats, it's possible for patron usage patterns to result in an imbalance in the collection -- more DVDs end up at Branch A and more books at Branch B. This can be especially troublesome when a given branch has limited shelving for a specific item type. I'd like to see a mechanism by which libraries can define a maximum count of items per item type to be allowed to float at a given branch. So, following my example above, Branch A could say that DVDs float when checked in but only up to 1000 items. If a DVD is checked in at Branch A and would be the 1001st DVD there, it instead transfers away. When some DVDs get checked out or transferred away, new returns will again be allowed to remain at Branch A. Setting the float limit to zero for a given item type and branch would make that item type always transfer away from that branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 245

[Bug 42958] New: Expand Elasticsearch/Opensearch usage across Koha beyond bibliographic search
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42958 Bug ID: 42958 Summary: Expand Elasticsearch/Opensearch usage across Koha beyond bibliographic search 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 42835 Blocks: 42508 Target Milestone: --- Koha's Elasticsearch/Opensearch integration is currently focused primarily on bibliographic records (the biblios and authorities indices). This META bug tracks efforts to extend Elasticsearch-backed search and indexing to other areas of Koha where it can improve performance, relevance ranking, and scalability over traditional SQL-based queries. Initial goals: - Provide Elasticsearch-backed indices for data types beyond bibliographic records - Reduce reliance on expensive SQL LIKE queries for search-heavy workflows - Enable faceting, relevance ranking, and full-text search in more areas of the staff interface and OPAC Potential future scope (not exhaustive): - Acquisitions/orders search - Serials search - Course reserves - Z39.50/SRU target expansion This is a tracking/collection bug only. Individual feature bugs should be filed separately and blocked against this one. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 [Bug 42508] Add Elasticsearch patron search feature https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 [Bug 42835] ElasticSearch should have an items index -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 11340] Make the 'print summary' a custom slip/notice
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11340 Tom Rice <tom.rice(a)cityofcarrollton.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tom.rice(a)cityofcarrollton.c | |om --- Comment #16 from Tom Rice <tom.rice(a)cityofcarrollton.com> --- I would love for this to be customizable. It prints out way too much PII -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41918] New: Prevent users from running the same report multiple times concurrently
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41918 Bug ID: 41918 Summary: Prevent users from running the same report multiple times concurrently 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 We have seen users reload and run long running reports when they do not get results in a timely manner. This can lead to server issues as the database resources are used up running many copies of the same report. We should allow any given report to only be run one execution at a time. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54