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

[Bug 41082] New: Renaming columns in reports doesn't work with batch tools
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41082 Bug ID: 41082 Summary: Renaming columns in reports doesn't work with batch tools Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com This is a bit of a curious case: When creating an SQL report and it contains the column itemnumber, we activate batch operations above the table. The itemnumber column can be renamed, using the syntax [[itemnumber|Exemplarnummer]], which gives us the option to translate the column name into something nicer for display. But: if you then send to batch item edit, the items are not transmitted. To test: 1) Create a report: select itemnumber, itemcallnumber from items; 2) Send some items to batch item edit, verify the items are shown above the item form 3) Update the report: select [[itemnumber|Exemplarnummer]], itemcallnumber from items; 4) Verify the report still shows as before with the batch options available and only the column being renamed. 5) Send some items to the batch item edit again, verify the items are NOT shown abvoe the item form => nothing would be batch edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

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

20 May '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 63

[Bug 39658] New: Allow definition of non-hierarchical linked patron accounts
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39658 Bug ID: 39658 Summary: Allow definition of non-hierarchical linked patron accounts Change sponsored?: --- Product: Koha Version: Main 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 In a Koha system containing multiple functionally-autonomous libraries, one patron may have multiple distinct accounts within the same Koha system. These accounts represent distinct cards from distinct libraries and need their circulation rules enforced as such, so they can't be merged into one account. But no one of these accounts is "primary" and they all represent the same person, so guarantor/guarantee relationships are a poor conceptual fit (and may already be in use for their intended purpose). These linked/shared accounts would: - clearly link between each other in the Details of the patron record - optionally reciprocally enforce restrictions and blocks due to fines & fees (when one account is blocked, all are) - optionally allow checkout of on-hold items for shared accounts For that last item, assuming one patron has accounts card1 and card2. They have a hold ready for pickup on their card1 account. If Koha attempts to check the waiting item out to the card2 account, koha should check the item out on the card1 account, mark the hold complete, and give the user a clear on-screen message as to what happened. It should not ask for confirmation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 142

[Bug 40251] New: Icon for self-check user permission
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40251 Bug ID: 40251 Summary: Icon for self-check user permission Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha displays icons for users with catalogue permissions, super librarian users, and protected users. But it would be nice if there was an easy way to see that an account is also a self-check user with either self_checkout_module or self_checkin_module since those users have only those permissions and not catalogue. This would also make troubleshooting easier to be able to see at a glance, both for ruling out permissions issues with the self-check module itself AND in cases where users who shouldn't have it do, since self_checkout_module creates permissions conflicts on staff accounts if selected by accident. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 40788] New: Add a custom event to Vue/Vue Islands when the Vue is loaded
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40788 Bug ID: 40788 Summary: Add a custom event to Vue/Vue Islands when the Vue is loaded Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To make Vue/Vue Islands work with customization from IntranetUserJS we need to add a custom event to tell JS the content is loaded. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 39981] New: Patron extended attribute search only available at patrons page
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39981 Bug ID: 39981 Summary: Patron extended attribute search only available at patrons page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikko.liimatainen(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you have selected patron attribute to be searchable in staff patron searches, this can only be done in the patrons page. However there are many other pages that have the patron search box available where you can't search with the extended patron attributes. I think patron attribute search should be available always when patron search is available. It would be more consistent with the description of the preference. "Check to make this attribute searchable in staff patron searches. If checked, this attribute will appear in patron search dropdowns." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 39094] New: Adjust system preferences to account for new option to refund the previous lost fee when marking an item Claims returned
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39094 Bug ID: 39094 Summary: Adjust system preferences to account for new option to refund the previous lost fee when marking an item Claims returned Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33292 ClaimReturnedChargeFee has the option to charge a lost fee, don't charge, or ask if a lost fee should be charged, when marking an item claims returned. These options should be update to reflect the new option to refund the previous lost item fee. Currently, if the preference is set to "ask if a lost fee should be charged", the modal shows two checkboxes: "Charge a lost fee" and "Refund previous lost fee". If the preference is set to charge or don't charge, the checkbox for "Charge a lost fee" is (correctly) not displayed, but the checkbox for "Refund previous lost fee" is also not displayed. It's a bit odd to show either both checkboxes or neither. It would also be nice to have the same options for refunding the lost fee that we currently have for charging a lost fee (refund, don't refund, or ask). We should add more options to ClaimReturnedChargeFee, or add a ClaimReturnedRefundFee preference. Somewhat relatedly, if we are going to allow the modal to give the user both options to charge or refund (or neither), we should use radio buttons or a drop-down in that case, rather than checkboxes, since it does not make sense to check both at once. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33292 [Bug 33292] Claim return doesn't refund lost item charge when MarkLostItemsAsReturned includes "When marking an item as a return claim" and "Refund lost item fee" is on -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 27919] New: Split Claims Return from LOST
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27919 Bug ID: 27919 Summary: Split Claims Return from LOST Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be helpful to libraries if Claims Returned was moved out of the Lost Value. It is confusing for patrons and staff to see a Claims Return as a Lost item, and there are times when an item needs to be marked both as Lost and as Claim Return, and combining those into one field can be a challenge. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 33997] New: Borrowers.updated_on should not be updated by track_login
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33997 Bug ID: 33997 Summary: Borrowers.updated_on should not be updated by track_login 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently borrowers.updated_on is updated by track_login even though a login is not an update to the patron record. This update needs to be blocked so that the updated_on field accurately reflects updates to the patron. Logins are supposed to be tracked by borrowers.lastseen which track_login already does. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 40368] New: Predictive patron search does not handle very similar first and last names
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40368 Bug ID: 40368 Summary: Predictive patron search does not handle very similar first and last names Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using predictive patron search, patrons that have similar first and last names do not get predicted or appear at the top of the search results. To recreate: Create a handful of patrons with the last name Johnson. Create a patron named John Johnson. Search for Johnson, John. You will notice the patron does not appear in predictive search, it will not redirect to that patron's account page, and their name/entry will not appear in the top of the search results. This makes it difficult to find these patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7