When modifying bibliographic record, Koha records in the log the original version of the record. This allows one to see what has been changed in the record. However, in case of item modification Koha records in the log the the current version of the item (i.e. the version after the edit). This is inconsistent with the biblio modification behavior and makes it difficult or even impossible to trace changes (especially in case of the first modif since the initial version is not being recorded). The ability to track changes is quite important for library staff and the inconsistency here is not understandable.
Created attachment 169855 [details] [review] Bug 37522: Logging item modification should record the original version of the item When modifying bibliographic record, Koha records in the log the original version of the record. This allows one to see what has been changed in the record. However, in case of item modification Koha records in the log the the current version of the item (i.e. the version after the edit). This is inconsistent with the biblio modification behavior and makes it difficult or even impossible to trace changes (especially in case of the first modif since the initial version is not being recorded). This patch makes the item modification logging feature work similarly to logging modifications in bibliographic records. Test plan: ========== 1. With CataloguingLog enabled (default in ktd) make a modification of an item. 2. Check the Modification log. You should see as the recorded varsion the version of the item after the modification. 3. Apply the patch; restart_all. 4. Repeat p. 1. 5. In the Modification log you should see now the version of the item that existed before the recent modification. Sponsored-by: Ignatianum University in Cracow
Created attachment 169862 [details] [review] Bug 37522: Logging item modification should record the original version of the item When modifying bibliographic record, Koha records in the log the original version of the record. This allows one to see what has been changed in the record. However, in case of item modification Koha records in the log the the current version of the item (i.e. the version after the edit). This is inconsistent with the biblio modification behavior and makes it difficult or even impossible to trace changes (especially in case of the first modif since the initial version is not being recorded). This patch makes the item modification logging feature work similarly to logging modifications in bibliographic records. Test plan: ========== 1. With CataloguingLog enabled (default in ktd) make a modification of an item. 2. Check the Modification log. You should see as the recorded version the version of the item after the modification. 3. Apply the patch; restart_all. 4. Repeat p. 1. 5. In the Modification log you should see now the version of the item that existed before the recent modification. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Hi, can you please detail how it works/should work (before/after)? If I understand correctly it changes from logging the new version to logging the old version. I think this would be a behavior change for libraries working with the logs and it would not be "visible" when the change occurred in the logs. We discussed at one of the last meetings a new coding guideline that new log entries should be using the new JSON diff. Could you have a look please? https://wiki.koha-community.org/wiki/Coding_Guidelines#ACTN1:_New_additions_to_actions_logs_should_use_the_JSON_Diff_format
(In reply to Katrin Fischer from comment #3) > Hi, can you please detail how it works/should work (before/after)? Now: 1) log records previous version of modified biblio record (very useful); 2) log records current version of modified item record (which is inconsistent with biblio behavior; not useful, since we have the current version in the database; leading to data loss in case of the first modif: the initial values go to /dev/null--which is most frustrating when working with the logs). Also note that the librarian sees the changes both of the biblio record and item record in one single table, but the meaning of the rows is opposite. It is my strong conviction that is should be consistent (the inconsistency here is not understandable for the librarians) and that it is probably buggy, maybe from the very beginning (the initial value of the item is never recorded in the log). > If I understand correctly it changes from logging the new version to logging > the old version. Yes--for items. > I think this would be a behavior change for libraries working with the logs > and it would not be "visible" when the change occurred in the logs. Yes, it changes the behavior for better, IMHO, by eliminating the (most probably buggy) inconsistency. > We discussed at one of the last meetings a new coding guideline that new log > entries should be using the new JSON diff. Could you have a look please? > > https://wiki.koha-community.org/wiki/Coding_Guidelines#ACTN1: > _New_additions_to_actions_logs_should_use_the_JSON_Diff_format The proposed patch make use of the diff feature: after applying it action_logs.diff column is filled as well, according to the proposal (but not visible from the interface).
Thanks for the replies and sorry for not coming back to this earlier. I am resetting to SO and I think another set of eyes would be good. Also adding Kyle and Nick.
Module changes need tests. Please add.
Created attachment 171520 [details] [review] Bug 37522: Unit tests NB, since the 6th argument to logaction is now mandatory for logging item modifications, one had to modify one line from the previous tests by adding this additional parameter.
Created attachment 171566 [details] [review] Bug 37522: Logging item modification should record the original version of the item When modifying bibliographic record, Koha records in the log the original version of the record. This allows one to see what has been changed in the record. However, in case of item modification Koha records in the log the the current version of the item (i.e. the version after the edit). This is inconsistent with the biblio modification behavior and makes it difficult or even impossible to trace changes (especially in case of the first modif since the initial version is not being recorded). This patch makes the item modification logging feature work similarly to logging modifications in bibliographic records. Test plan: ========== 1. With CataloguingLog enabled (default in ktd) make a modification of an item. 2. Check the Modification log. You should see as the recorded version the version of the item after the modification. 3. Apply the patch; restart_all. 4. Repeat p. 1. 5. In the Modification log you should see now the version of the item that existed before the recent modification. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 171567 [details] [review] Bug 37522: Unit tests NB, since the 6th argument to logaction is now mandatory for logging item modifications, one had to modify one line from the previous tests by adding this additional parameter. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Looks good! It does make me wonder if we should be storing a JSON diff for object creation as well. I'm not sure if that is within the scope of this bug though.
(In reply to Kyle M Hall from comment #10) > Looks good! It does make me wonder if we should be storing a JSON diff for > object creation as well. I'm not sure if that is within the scope of this > bug though. Thank you, Kyle, for the remark. I think, this is beyond the idea of this patch. In fact, we probably should make a general review od all logaction calls and add the 6th argument to consistently create the content ot the diff column, as you made it in bug 25159 for holds. (In case of item creation and also changes made to bibliographic records this does not seem to be straightforward...)
(In reply to Janusz Kaczmarek from comment #11) > (In reply to Kyle M Hall from comment #10) > > Looks good! It does make me wonder if we should be storing a JSON diff for > > object creation as well. I'm not sure if that is within the scope of this > > bug though. > > Thank you, Kyle, for the remark. I think, this is beyond the idea of this > patch. In fact, we probably should make a general review od all logaction > calls and add the 6th argument to consistently create the content ot the > diff column, as you made it in bug 25159 for holds. (In case of item > creation and also changes made to bibliographic records this does not seem > to be straightforward...) Agreed. I will file a followup bug report!
Created attachment 173547 [details] [review] Bug 37522: Logging item modification should record the original version of the item When modifying bibliographic record, Koha records in the log the original version of the record. This allows one to see what has been changed in the record. However, in case of item modification Koha records in the log the the current version of the item (i.e. the version after the edit). This is inconsistent with the biblio modification behavior and makes it difficult or even impossible to trace changes (especially in case of the first modif since the initial version is not being recorded). This patch makes the item modification logging feature work similarly to logging modifications in bibliographic records. Test plan: ========== 1. With CataloguingLog enabled (default in ktd) make a modification of an item. 2. Check the Modification log. You should see as the recorded version the version of the item after the modification. 3. Apply the patch; restart_all. 4. Repeat p. 1. 5. In the Modification log you should see now the version of the item that existed before the recent modification. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 173548 [details] [review] Bug 37522: Unit tests NB, since the 6th argument to logaction is now mandatory for logging item modifications, one had to modify one line from the previous tests by adding this additional parameter. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(In reply to Kyle M Hall (khall) from comment #10) > Looks good! It does make me wonder if we should be storing a JSON diff for > object creation as well. I'm not sure if that is within the scope of this > bug though. We shoudld we have a coding guideline now enforcing this for new logs too :)
Please explain the consequence of this change for the release notes, thanks!
Pushed for 24.11! Well done everyone, thank you!