One of our libraries was trying to track down an issue where a patron was charged an enrollment fee -- looking at the patron's category code, it was clear that the patron was not currently in a category that should have been charged. I wanted to see if the patron's category code had changed. Here's what I found in action_logs: select * from action_logs where object='5056' and module='MEMBERS'; +-----------+---------------------+------+---------+--------+--------+--------------------------------+ | action_id | timestamp | user | module | action | object | info | +-----------+---------------------+------+---------+--------+--------+--------------------------------+ | 1109625 | 2015-12-02 15:36:32 | 3805 | MEMBERS | CREATE | 5056 | | | 1109636 | 2015-12-02 15:58:28 | 3804 | MEMBERS | MODIFY | 5056 | UPDATE (executed w/ arg: 5056) | | 1109637 | 2015-12-02 16:02:50 | 3804 | MEMBERS | MODIFY | 5056 | UPDATE (executed w/ arg: 5056) | +-----------+---------------------+------+---------+--------+--------+--------------------------------+ The 'info' field simply tells me that patron 5056 was modified -- which doesn't give me any information that I couldn't glean from the 'object' and 'action' fields -- I really needed to know which fields in the borrower record were changed.
(In reply to Barton Chittenden from comment #0) > 'action' fields -- I really needed to know which fields in the borrower > record were changed. ... as well as what the field changed from and to. I *don't* want to see the entire borrower record though.
For the CREATE we should list the key/value pairs that are actually set in 'info'. For UPDATE we should list the kye/value pairs that have *changed* in "info". This may be useful: http://www.perlmonks.org/?node_id=752303
I agree that the info column doesn't give useful information. There is already a kind of diff in the cataloguing action_logs, which I find somewhat useful because it gives you the "biblio before" so you can compare and see what changed. It would be even better if there was the before / after but something similar would be a good first step for the patron file.
*** This bug has been marked as a duplicate of bug 3820 ***