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

[Bug 37884] New: Interface in action logs for renewals is OPAC if the previous renewal was in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37884 Bug ID: 37884 Summary: Interface in action logs for renewals is OPAC if the previous renewal was in the OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When you do a renewal in the staff interface, and the previous renewal was in the OPAC, the actions logs will say it was done in the OPAC. To recreate: 1. Enable RenewalLog 2. Check out an item to patron A 3. Check out another item to patron B 4. Log in the the OPAC as patron A and renew the checkout 5. In the staff interface, renew the checkout for patron B 6. Go to Tools > Log Viewer 7. Check the Circulation module and click OK --> Both renewals have the interface "OPAC" It seems to be a cookie thing maybe? If I do the OPAC renewal in a private browser window, it's ok. I realize this is unlikely to happen in real life, I was trying to create log entries for the manual. But I don't know enough to know if this is a symptom of a bigger problem or not, so I figured I'd report it... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37073] New: Action logs should include the logged in library for user
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37073 Bug ID: 37073 Summary: Action logs should include the logged in library for user Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jheltibridle(a)rcplib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a user modifies a patron account, the action logs should include the logged in library for the user. A use case scenario for this is our system, which has two branches for a library, but all users and borrowers of that library are set to one branch as their home. The users sometimes are logged into the second branch and make actions on patrons accounts, but there is no way of knowing if the action was taken while at the first branch or the second. Adding the user's logged in library to the action_logs would make this information available. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22974] New: Patron password update validation broken
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22974 Bug ID: 22974 Summary: Patron password update validation broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21964 Target Milestone: --- Bug 21946 (accidentally) removed inclusion of str/members-menu.inc, breaking JavaScript validation of the two password fields on the "change password" page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21964 [Bug 21964] Switch two-column templates to Bootstrap grid: Patrons part 2 -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 36354] New: Action log viewer should give option to search by object type (item, biblio, borrowernumber, reserve_id sql.id etc)
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36354 Bug ID: 36354 Summary: Action log viewer should give option to search by object type (item, biblio, borrowernumber, reserve_id sql.id etc) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 There is no way to specify what kind of object you want to be searching for. Some of the modules will limit to only one (report for example) but cataloging searches by itemnumber unless you go directly from the bib. An option to specify would be helpful . -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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