Bug 35630 - Add ability to log changes to authorized values
Summary: Add ability to log changes to authorized values
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Sam Lau
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 22794
  Show dependency treegraph
 
Reported: 2023-12-21 18:09 UTC by Donna
Modified: 2024-07-11 12:49 UTC (History)
10 users (show)

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


Attachments
Bug 35630: Add new system preference 'AuthorizedValuesLog' (3.26 KB, patch)
2024-07-10 15:15 UTC, Sam Lau
Details | Diff | Splinter Review
Bug 35630: Add ability to log creation, modification, and deletion of authorized values (7.32 KB, patch)
2024-07-10 15:15 UTC, Sam Lau
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Donna 2023-12-21 18:09:31 UTC
With the increase in number of authorized values, and with the newer sys pref CreateAVFromCataloguing, it is becoming essential to be able to determine who/when/how changes are made to authorized values, and this not currently being logged.  It would be a great help to be able to log these changes.
Comment 1 Laura O'Neil 2024-01-18 20:25:34 UTC
+1, this would be extremely useful.
Comment 2 Chris Rowlands 2024-07-08 08:00:48 UTC
As a system librarian trying to work out if I've made a change to an auth value, or someone else did it without my input, I'd love this feature to exist!
Comment 3 Sam Lau 2024-07-10 15:15:36 UTC
Created attachment 168747 [details] [review]
Bug 35630: Add new system preference 'AuthorizedValuesLog'
Comment 4 Sam Lau 2024-07-10 15:15:38 UTC
Created attachment 168748 [details] [review]
Bug 35630: Add ability to log creation, modification, and deletion of authorized values

These patches enable librarians to log any changes to authorized values. The feature is dependent on the new 'AuthorizedValuesLog' system preference.

To test:
1) Apply patch, updatedatabase, restart_all
2) In Administration->System preferences, search for 'AuthorizedValuesLog' and change to 'Log'. Save your changes.
3) Now go to Administration->Authorized values. Keep this tab open
4) In a new tab, go to Tools -> Log viewer. Ensure that "Authorized values" is checked.
5) Now in AV, click on a category and create a new authorized value.
6) Refresh your log viewer, and the creation should be logged appropiately.
7) Modify an authroized value, this should also be logged correctly.
8) Now delete and authorized value, ensure the logging is correct here as well.
9) Now turn off the system preferece.
10) In the log viewer, 'Authorized values' should have a black triangle next to it, indicating the preference is turned off.
11) Change an AV, this should not be logged.
Comment 5 Roman Dolny 2024-07-10 17:57:24 UTC
It works as described it test plan, but:

1. QA - Not blocker: Sysprefs IntranetAddMastheadLibraryPulldown is bad placed (see bug 10610)

2. What should be recorded into 'info' column in action_logs table? Value before modification or value after mod.? For bibliographic record it is value before modification.
Comment 6 Sam Lau 2024-07-10 18:12:06 UTC
(In reply to Roman Dolny from comment #5)
> It works as described it test plan, but:
> 
> 1. QA - Not blocker: Sysprefs IntranetAddMastheadLibraryPulldown is bad
> placed (see bug 10610)

This is unrelated to this bug.

> 2. What should be recorded into 'info' column in action_logs table? Value
> before modification or value after mod.? 

I would think the value after modification. If you wanted to see the value before modifcation, then you would just go back into the logs. 

> For bibliographic record it is value before modification.

I see what you are saying about editing a record, but there's examples where it goes the other way as well. For example, when editing a specific item, the logs show the value after. I think this is better behavior
Comment 7 Roman Dolny 2024-07-10 19:02:19 UTC
(In reply to Sam Lau from comment #6)
> 
> ...
> 
> > 2. What should be recorded into 'info' column in action_logs table? Value
> > before modification or value after mod.? 
> 
> I would think the value after modification. If you wanted to see the value
> before modifcation, then you would just go back into the logs. 
> 

This works for new values and subsequent modifications of values before logging begins. But not for the first modification of values currently existing in the database. (But I'm not sure if this is really important.)

Maybe we should record the old and new value in the "info" column?
Comment 8 Lucas Gass 2024-07-10 19:57:31 UTC
> Maybe we should record the old and new value in the "info" column?

I think that is confusing. Why not just log the new value as MODIFY?
Comment 9 Katrin Fischer 2024-07-11 12:49:04 UTC
We pushed bug 25159 to the end of the cycle and I feel like we should make use of it when adding new logs now.
Adding Kyle and also a topic to next meeting agenda:
https://wiki.koha-community.org/w/index.php?title=Development_IRC_meeting_17_July_2024&action=submit
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35630
bugs.koha-community.org
CC-MAIN-2024-30
41381
application/http; msgtype=response
sha1:PKAK3V2YDOJDJVTVAMRDZAVUVKHWYXJQ
<urn:uuid:6009000a-bdff-43fe-9865-31b7b6f3ebf3>
2024-07-14T23:23:23Z
72.14.190.217
text/html
sha1:T7CQOY7YKZC2KF7Y3M7N5NES4KA6RU52
<urn:uuid:0baa2865-9acd-438b-81a7-e3b0bf56864b>
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35630
response
<urn:uuid:cf765eb2-3851-4b33-a051-18f4e74f03c0>
isPartOf: CC-MAIN-2024-30
publisher: Common Crawl
description: Wide crawl of the web for July 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-161
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/