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

[Bug 35991] New: C4::Items::AddItemBatchFromMarc should not call logaction()
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35991 Bug ID: 35991 Summary: C4::Items::AddItemBatchFromMarc should not call logaction() Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl C4::Items::AddItemBatchFromMarc calls logaction() : https://git.koha-community.org/Koha-community/Koha/src/commit/12b6c0e67d395… But this action is already done by Koha::Item->store() a few line above. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 35988] New: Record of deleted item not recorded in action logs even if record wasn't deleted
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35988 Bug ID: 35988 Summary: Record of deleted item not recorded in action logs even if record wasn't deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 161736 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161736&action=e… Screenshot of object column for deleted items. When an item is deleted, it shows in the action logs that "Item number was deleted from Bibliographic record " There is no indication of which bibliographic record the item was attached to, even when the record still exists. Both links are useless as the items have been deleted the bibliographic link has no number associated with it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 35499] New: Lost item blocked at checkin still logs a return in action logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35499 Bug ID: 35499 Summary: Lost item blocked at checkin still logs a return in action logs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I found this while investigating something for a client and noticed that in the patron's modification log, an item was checked out once and checked in twice. It seems if you try to check in a lost item and BlockReturnOfLostItems is set to block, an action_log of the return is still logged (with nothing different from a log of a real checkin). I don't know if this is normal, but it doesn't feel normal. To recreate: 1. Make sure BlockReturnOfLostItems is set to Block 2. Make sure MarkLostItemsAsReturned is set to nothing (or at least not From the items tab of the catalog module) 3. Make sure ReturnLog is set to Log 4. Check out an item to a patron 5. In the list of checkouts, click the barcode and set the status to Lost 6. Try to check in the item --> should be blocked and say Item is lost, cannot be checked in. ; Cannot check in ; NOT CHECKED IN 7. Go to the patron's file and click the Modification log button --> Note that there is a line for the return of the item 8. Go back to the item and change the status back to not lost 9. Check in the item again --> Should check in normally 10. Go to the patron's file > Modification log --> Note that there is a new line for the return of the item; both lines are identical, there is nothing that indicates one return was not successful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32700] New: Action logs logging should be divided into smaller components to reduce table size
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32700 Bug ID: 32700 Summary: Action logs logging should be divided into smaller components to reduce table size Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In Koha-Suomi our action_logs tables fill up with tens of millions rows of data in one year. For example our Vaski-libraries had accumulated 800 000 entries in one week. To be able to manage this massive amount of data (cleanups/archiving) better, Koha should save the actions to dedicated tables based on interface for example. Currently we archive the action_logs table each year to archive tables based on the year found on timestamps. If the data was split into smaller tables based on interface we could better organize these cleanups. The time it takes to make archived tables and reinserting newest entries back to a clean active action_logs table would take far less time with invidual action_log tables based on interface (action_logs_api etc.). Also deciding the time of storage might be easier based on interface. Moving millions of rows with massive time taking insert queries takes almost up to a day for us and would eventually bring Koha to a halt. Ps. After we moved to version 21.11 last year, the amount of data written to action_logs has increased dramatically due to various logging settings we want to have enabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28714] New: Bib record change tracking action log
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28714 Bug ID: 28714 Summary: Bib record change tracking action log Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When looking at action logs to see the changes in a bib record, the logs only show the updated info, and no info about what was actually changed. It would be much more helpful to see what information was changed in the bib record, a before and after sort of thing. Other logs show the changes, such as when modifying items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 22855] New: Hold information hashes should be dumped to action_logs in sorted key order
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22855 Bug ID: 22855 Summary: Hold information hashes should be dumped to action_logs in sorted key order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- All of the HOLDS-module entries saved into action_logs have hashes dumped into them, and the hash keys are in random order. The keys should be sorted instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21810] New: Add methods to allow deleting of action logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21810 Bug ID: 21810 Summary: Add methods to allow deleting of action logs Change sponsored?: --- Product: Koha Version: master 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently it is not possible to delete action logs since C4::Log does not provide any methods to do so. As detailed in bug 21809, it may, on occasions, be desirable to delete the logs associated with an object that has been deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41270] New: Two-factor authentication does not create entry in action_logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41270 Bug ID: 41270 Summary: Two-factor authentication does not create entry in action_logs Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.liddle(a)wycliff.de QA Contact: testopia(a)bugs.koha-community.org In advance of updating our production server from 22.11 LTS to 24.11 LTS, we are testing the use of the system preferences TwoFactorAuthentication (Enable) and TrackLastPatronActivityTriggers (Logging in) on the test server that has undergone this upgrade. I have enabled two-factor authentication on my own account. While examining the relationship between borrowers.lastseen and action_logs.timestamp, I noticed that the value for my lastseen in borrowers could not be correlated to an entry in action_logs. The last SUCCESS action for the AUTH module in action_logs appears to correlate only with the submission of the correct username and password. The timestamp for lastseen is newer and seems to correlate with the submission of the correct OTP code. There ought to be an entry in action_logs that reflects the success or failure of the 2FA challenge. Thanks! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40987] New: SIP data changes should be logged
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40987 Bug ID: 40987 Summary: SIP data changes should be logged Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When checking in items using a self-checkout machine via SIP, the changes to the items are not logged. For instance, when item A with a notforloan -1 status is checked in via SIP, its status becomes available, but the change from notforloan -1 to Available is not logged. It would be helpful if these types of changes were logged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 38648] New: Resolution of a claimed return is not logged
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38648 Bug ID: 38648 Summary: Resolution of a claimed return is not logged Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Assigning a lost status of claims returned is logged with the item. Resolution of the claimed return status is not logged. Another aspect of this is the patron log does not show a claim was made, nor does it log the resolution of the claim. Should the resolution of the claimed return be logged with the item or with the patron? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5