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

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

03 Jun '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 242

[Bug 40518] New: Add examples of leader fields to Advanced Editor section
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40518 Bug ID: 40518 Summary: Add examples of leader fields to Advanced Editor section Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de In the Koha Manual, for Macros in the Advanced Editor in this section: https://koha-community.org/manual/latest/en/html/cataloging.html#advanced-e… All the examples show updating specific subfields, so you have to just guess that you can update the contents of a control field (MARC 00x$) by just leaving out the subfield codes. (Like 000$, 001$... etc.) We should add an example of one of these leader fields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 40856] New: Improve Standard backend metadata retrieval
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40856 Bug ID: 40856 Summary: Improve Standard backend metadata retrieval Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The metadata() method in the Standard ILL backend uses an inefficient pattern for filtering attributes, performing a linear search through an ignore list for every attribute using grep inside a while loop. This approach becomes increasingly slow as the number of attributes grows, and manually iterates through all attributes instead of leveraging database-level filtering. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40855] New: Standard backend uses plain SQL
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40855 Bug ID: 40855 Summary: Standard backend uses plain SQL Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The edititem() method in the Standard ILL backend uses raw SQL queries with manual delete-all-and-recreate patterns instead of leveraging Koha's ORM. This approach creates several problems: it bypasses ORM validation and relationships, uses inefficient delete-all-then-insert operations that update unchanged attributes, includes complex conditional SQL based on column existence checks [1], and makes the code harder to maintain and debug. The method contains over 40 lines of raw SQL that could be replaced with a single call to add_or_update_attributes() (from bug 40850), which would be more efficient (only updating changed values), safer (using ORM validation), more maintainable (no raw SQL). [1] For backwards compatibility with older Koha versions? Inherited from the time it was an external backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41009] New: When editing an ILL request, the user is returned to the list
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41009 Bug ID: 41009 Summary: When editing an ILL request, the user is returned to the list Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com It should return to the request. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 31215] New: Add ability to select multiple items to remove from course_items
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31215 Bug ID: 31215 Summary: Add ability to select multiple items to remove from course_items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the only way to remove items from course reserves is to remove all reserves or select items individually to remove. For libraries that use course reserves with large courses, the ability to select multiple items at a time to remove would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22707] New: Allow manual definition of AutoMemberNum range
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22707 Bug ID: 22707 Summary: Allow manual definition of AutoMemberNum range Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Target Milestone: --- It'd be great to have a way to tell Koha where to start when assigning card numbers via AutoMemberNum and to see what the next number will be. Bug 19263 introduced a feature that uses an authorized value to set up ranges of auto-incremented control numbers in bib records. Could something similar be used for card numbers? Ideally, this could also allow the definition of separate card number ranges for different branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 33756] New: Wrong calculation of total amount spent?
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33756 Bug ID: 33756 Summary: Wrong calculation of total amount spent? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am trying to work out something in acquisitions and stumbled on this bit: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Bud… # Get all the budgets totals in as few queries as possible my $hr_budget_spent = $dbh->selectall_hashref(q| SELECT aqorders.budget_id, aqbudgets.budget_parent_id, SUM( | . C4::Acquisition::get_rounding_sql(qq|COALESCE(unitprice_tax_included, ecost_tax_included)|) . q| * quantity ) AS budget_spent FROM aqorders JOIN aqbudgets USING (budget_id) WHERE quantityreceived > 0 AND datecancellationprinted IS NULL GROUP BY budget_id, budget_parent_id |, 'budget_id'); If the amount is spent, I feel multiplying by quantity is incorrect. It should be quantityreceived. I am not sure yet where this is used and how it manifests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 38256] New: Link vendors to ERM data providers
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38256 Bug ID: 38256 Summary: Link vendors to ERM data providers Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There should be the ability to link an ERM data provider to a vendor record. This will enable us to get cost data from baskets/orders and link to usage statistics -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 24414] New: Can't add/delete funds with only budget_add_del permission
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24414 Bug ID: 24414 Summary: Can't add/delete funds with only budget_add_del permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is very minor, but I was trying out all the permissions to better document them in the manual and I found something weird. There are several permissions granting access to funds. - budget_add_del described as 'Add and delete funds (but can't modify funds)' - budget_manage described as 'Manage funds' - budget_manage_all described as 'Manage all funds' - budget_modify described as 'Modify funds (can't create lines but can modify existing ones)' If I only have budget_add_del, I can't create or delete funds. I have to have budget_manage to access the funds administration page. Which is ok, I can simply add a note in the manual that budget_add_del requires budget_manage. If I have budget_add_del and budget_manage, I have access to the funds administration page, but not the 'New fund' button nor the 'Actions' button to delete an existing fund. So in reality, I can't add nor delete funds... If I have budget_manage and budget_modify (but not budget_add_del), I can't add new funds I can't edit existing ones, but I can delete them. To test : 1) Create a patron and give them the catalogue permission and the budget_add_del permission 2) Log in with this patron (I use a private window to be able to go back and change their permissions later without logging out again) 3) Go to the Acquisitions page 4) Notice you can see the budget, but you can't click on the fund code and you don't have the 'Funds' link in the left menu 5) Go back to edit the user's permissions and grant them budget_manage; save 6) Go back to the Acquisition page with the limited patron (refresh if needed) 7) Notice that you can now click on the fund code and you have a 'Funds' link on the left side of the screen 8) Click on the fund code 9) Click on 'New' and choose 'Add fund for xx'; add the new fund 10) Notice there is no 'Actions' button from which you can delete this fund 11) Go back to edit the user's permissions and remove the budget_add_del permission and add the budget_modify; save 12) Go back to the Acquisition page with the limited patron (refresh if needed) 13) Click on the 'Actions' button and choose 'Edit'; the page refreshes, but nothing happens 14) Click on the 'Actions' button and choose 'Delete' and confirm; the fund is deleted I have trouble imagining a situation where we would want staff to be able to add and delete funds but not modify them, so that's why I said I think this is minor. I think in most cases, the staff member will have at least all three (budget_add_del, budget_manage and budget_modify). But I still wanted to record the weirdness somewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4