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

[Bug 40932] New: Automated trigger for invoice closure
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40932 Bug ID: 40932 Summary: Automated trigger for invoice closure Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org We would like to see the ability to set a trigger for a series of actions that would close an invoice automatically without us manually going into the invoice and ticking close and saving. We want to see a workflow whereby once all items associated to an invoice, when they are all returned for the first time this would trigger a cron job to close the invoice. This would help us to automate our acquisitions checking processes. Currently a staff member has to run a report and check in with staff to make sure they have returned items and then they spend a considerable time checking through for each invoice to make sure items have been physically received and then closing the invoice. If we can automate this last step so that when all items are checked in for the first time, the invoice will automatically close. It would also be useful to have this automatic action as a cron job so that if something goes wrong we could interrupt the next run and correct. Also, the ability to reopen the invoice is also the other failsafe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 41169] New: Cancelling order from a basket doesn't warn about removing items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41169 Bug ID: 41169 Summary: Cancelling order from a basket doesn't warn about removing items Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikko.liimatainen(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org When cancelling an order in a basket there is no warning about item deletion. This can be a problem if the item is already in circulation. If the items attached to the order can not be removed, this is given a notification as the order has been cancelled. When you are cancelling an order you get a confirmation page with this text: "Are you sure you want to cancel this order (45) Bibliographic record will not be deleted." I'd like there to be a mention that the items of this order will be deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 41451] New: Hold history search fails when itemtype column present
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41451 Bug ID: 41451 Summary: Hold history search fails when itemtype column present 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The search box on the holds history table throws a 500 error when the item type column is visible Test plan: 1) Create at least one hold on any record 2) Navigate to the patron who has the hold and click Holds history in the left menu 3) The table should load correctly and the search bar above it should work 4) In system preferences, enable AllowHoldItemTypeSelection 5) Refresh the holds history, the Requested item type column should now be visible 6) Try a search, a 500 error should be thrown -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 40933] New: Add sms support under Add message feature
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40933 Bug ID: 40933 Summary: Add sms support under Add message feature 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: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Staff interface -> Patron details -> Add Message Current options are: Staff - Internal note OPAC Email - email addresses of patron Add: SMS - sms number of patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 36583] New: MEMBERSHIP_RENEWED message for manual renewals
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36583 Bug ID: 36583 Summary: MEMBERSHIP_RENEWED message for manual renewals Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries who require in-person patron account renewals (so that they can confirm contact information etc.) may also want to send a record of the renewal to their patrons, so it would be nice if the new MEMBERSHIP_RENEWED notice coming with bug 28688 could be sent for manual patron account renewals, not just for automatic account renewals via the membership_expiry.pl cron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 26355] New: Tie account renewals to patron modification requests
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 Bug ID: 26355 Summary: Tie account renewals to patron modification requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Allow patrons renewal reminders to link to the patron modification requests, asking them to review their information and make any any necessary updates if necessary, but acknowledging that the information is up to date. Create a check-box stating that they have reviewed all their information, and it is accurate and up to date (if no changes are made). Perhaps this check-box only shows when their account is due for renewal. -- You are receiving this mail because: You are watching all bug changes.

1 265

[Bug 27066] New: Implement Hooks for patron's updates
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27066 Bug ID: 27066 Summary: Implement Hooks for patron's updates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: eric.begin(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Some of our clients use external systems to populate Koha's patron information. They can use Koha's API to update patron info, however, we don't have any way (that I know of) to notify an external system when a patron info is changed in Koha. In order to allow bidirectional communications, we are planning to add hooks. This will allow creating plugins to send messages to external systems in order to fulfil the following requirements : - Update patron information stored in the borrowers table (name, address, email, etc.) - Notify an external system when a restriction is placed on a user (fines, manual restrictions, overdues, etc.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 39461] New: Cite feature
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39461 Bug ID: 39461 Summary: Cite feature Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Style guide Assignee: oleonard(a)myacpl.org Reporter: lrudikoff(a)massbay.edu QA Contact: martin.renvoize(a)openfifth.co.uk I have a lot of issues with the Cite feature in KOHA (the Cite in Zotero is fine). Personally, I don't like it as it is not correct at all! For example, the entire title of the item is not listed, there is no complete name of the author, and there is no italicizing for citation styles that use it. It also doesn't list which Chicago style it is using. Why is there both a Cite and Cite in Zotero? As a user, I would not scroll down to see the Cite in Zotero and just use the Cite feature which is listed first. -- You are receiving this mail because: You are watching all bug changes.

1 11

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

21 Oct '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 169

[Bug 40117] New: Add option for modification of not for loan from items tab
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40117 Bug ID: 40117 Summary: Add option for modification of not for loan from items tab Change sponsored?: --- 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: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Not for loan is a powerful status with a lot of flexibility for libraries, especially since it has the -/+ holdable but not circulating/does not circulate capability. And many libraries are not using it to full advantage because the only way to edit it is from the edit item form, not easily accessible from the items page (moredetail.pl) like other statuses. It would be nice if, perhaps by system preference, a library could optionally make editing of the not for loan status available from moredetail.pl. That way libraries that want NFL status updating a bit more locked down can still only access it from editing an item, and libraries that want staff to be able to use more flexible statuses make it more accessible to staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25