Bug 31520 - Only log ILL changes that are actual changes
Summary: Only log ILL changes that are actual changes
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: ILL (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-05 08:47 UTC by Magnus Enger
Modified: 2022-09-05 08:47 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2022-09-05 08:47:12 UTC
"Bug 20750 - Allow timestamped auditing of ILL request events" added the ability to log status changes to ILL requests, in the action_logs table, with action = 'STATUS_CHANGE'. 

I have an ILL setup where a remote API is checked for data every 3 minutes, and requests are updated. With Illlog = on, this leads to 480 action_logs entries per 24-hour period. I have a test setup where the amount of logs was causing the detailed display of illrequests to time out, because there were so many log entries to fetch. 

This could be improved if we only logged actual status changes. Today there is a log entry even if the status is not changed: 

| ILL    | STATUS_CHANGE | {"status_after":"IN_LEV","log_origin":"core","status_before":"IN_LEV"} |
| ILL    | STATUS_CHANGE | {"status_after":"IN_LEV","status_before":"IN_LEV","log_origin":"core"} |
| ILL    | STATUS_CHANGE | {"status_before":"IN_LEV","status_after":"IN_LEV","log_origin":"core"} |
| ILL    | STATUS_CHANGE | {"log_origin":"core","status_before":"IN_LEV","status_after":"IN_LEV"} |
| ILL    | STATUS_CHANGE | {"status_before":"IN_LEV","status_after":"IN_LEV","log_origin":"core"} |
| ILL    | STATUS_CHANGE | {"status_after":"IN_LEV","log_origin":"core","status_before":"IN_LEV"} |
+--------+---------------+------------------------------------------------------------------------+

We could compare status_before and status_after, and only log if they differ.