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

[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

[Bug 12450] Easily close a branch
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12450 --- Comment #18 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Another aspect that makes this a MUCH NEEDED FEATURE is that we are currently working on adding new libraries to our system. There is currently no way to make a branch unavailable to staff or patron when setting up the new branch. They will be visible the moment the branch is added. This aspect might be a step beyond closure because it adds the added question as to whether or not the branch should be seen by staff/patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43248] New: Lost, not for loan, withdrawn, and damaged statuses not considered in library float limits ratio calculations
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43248 Bug ID: 43248 Summary: Lost, not for loan, withdrawn, and damaged statuses not considered in library float limits ratio calculations Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: bwsdonna(a)gmail.com, gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 28530 Target Milestone: --- It appears that lost, not for loan, withdrawn, and damaged statuses are not taken into account when Koha calculates libraries' library float limit ratio of available to max items, and thus aren't considered when determining which library should receive items. To replicate: -Set library float limits so that there will be a 'tie' for the lowest ratio between two branches (for instance, a Book limit of 10 at North and West branches, and 5 at East and South) -Distribute the holding library for Books so that North and West each have 7, and East and South each have 6. Thus, North and West have the same lowest ratio. -Set 5 of North's Books to any lost status (no other statuses apply to any other items at North or West) -Make sure that none of the North and West Books are checked out -*Repeat multiple times*: Check in a Book at South, and note the transfer target. Cancel the transfer, repeat the check in, and note that Koha randomly selects between North and West with each transfer. Ideally, the item would transfer to North since there are fewer *available* Book items. The same random selection of West or North happens when the majority of North's items are set to a withdrawn, damaged, or not for loan status. 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 1

[Bug 43247] New: Transfer reason doesn't show in Checked-in items table for float limit transfers
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43247 Bug ID: 43247 Summary: Transfer reason doesn't show in Checked-in items table for float limit transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Depends on: 28530 Target Milestone: --- When an item is checked in and is sent to transfer due to the new library float limits feature, the 'Transfer reason' column is blank in the 'Checked-in items' table. The reason shows in logs as 'LibraryFloatLimit', so Koha has the information - it's just not displaying it in that table. 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 0

[Bug 26955] New: Allow macros in Advanced Cataloging Editor to be renamed
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '26

07 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26955 Bug ID: 26955 Summary: Allow macros in Advanced Cataloging Editor to be renamed Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Once you create a macro in the Advanced Cataloging Editor it cannot be renamed - you have to delete it and re-enter it with a new name. Being able to edit the name of the macro would be more efficient. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7