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

[Bug 42649] New: Koha package upgrade also upgrades DB for disabled instances
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42649 Bug ID: 42649 Summary: Koha package upgrade also upgrades DB for disabled instances Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com The majority of koha-* commands just work on enabled instances, but in debian/koha-common.postinst we run "koha-upgrade-schema $(koha-list)" Might it not be better to do "koha-upgrade-schema $(koha-list --enabled)"? On one hand, there's merit to making sure all databases are upgraded. On the other hand, you might've disabled an instance because it has problems with its database, and then the koha-upgrade-schema fails spectacularly on that problem database. It's easy to upgrade a database later, so I think it might be better to just upgrade enabled Koha instances. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 41993] New: Add a datatable to list available bookings
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41993 Bug ID: 41993 Summary: Add a datatable to list available bookings 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 @ll Like the datatable containing pending bookings, it may be useful to add a table displaying the list of bookable items. This would take into account specific rules (lead and trail periods) and be joined with current checkouts to certify their availability. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42644] New: Batch catalog record modification success message is early
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42644 Bug ID: 42644 Summary: Batch catalog record modification success message is early Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a batch record modification job in Cataloging (Cataloging > Batch editing > Batch record modification) is enqueued, as soon as the job has a status of "started" the onscreen report states "All records have been successfully modified!". This shows even if the progress report indicates no records have yet been processed. This report message is misleading. It should wait until the job reaches "finished" status. If any report message is wanted for in-progress jobs, when the status is "started" something like "All records are queued for modification" would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[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

[Bug 42635] New: Staff interface curbside pickups - improve slots selection
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42635 Bug ID: 42635 Summary: Staff interface curbside pickups - improve slots selection Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This patch will copy some of the CSS from the OPAC template in order to improve the style of the curbside pickups slot selection. The patch will also convert the form to a CSS grid-styled form. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 38902] New: Allow holds fine limit (maxoutstanding) to be determined by patron category
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38902 Bug ID: 38902 Summary: Allow holds fine limit (maxoutstanding) to be determined by patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: raina(a)flo.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The system preference “maxoutstanding” is used to determine when patrons are blocked from making holds in the OPAC. For example, maxoutstanding: Prevent patrons from making holds on the OPAC if they owe more than 5 USD in fines. This is separate from the checkout fine limit (noissuescharge). Currently the maxoutstanding preference is applied to all patrons, and there's no way of changing the value for individual patron categories. Bug 28924 enables checkout fine limit to be set by patron category, but there's no way of changing the value for "maxoutstanding" by patron category, which means that all patron groups will still be blocked from placing holds in the OPAC at the same amount. It would be helpful to be able to determine when patrons should be blocked from making holds in the OPAC by patron category, like bug 28924 does for the checkout fine limit. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41991] New: Temporarily suspend a plugin method or specific plugin class
by bugzilla-daemon＠bugs.koha-community.org 19 May '26

19 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41991 Bug ID: 41991 Summary: Temporarily suspend a plugin method or specific plugin class Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This starts from a use case where I do want to suspend a certain item plugin hook for a specific command line process. But I dont want to disable the plugin for all processes. So yes, this requires enough understanding from the admin who does that. My idea is to introduce something similar here to the override_syspref construct. To allow suspending a plugin method or class via an environment variable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49