Keeping deleted users in the Audit log

[schris-dk]

Proposal

Keep information of deleted/deactivated users in the user database

Motivation and context

To be able to determine who accessed a particular report back in time, it would be of value to keep deleted users in the Users view.

This is not only useful - but also helping to comply with audit legislation and archiving legislation, as these can demand, that you are able to document things X number of years back in time (Danish archiving legislation says 5 years).

I'd suggest 2 different ways to deal with this:

1) keep the info in the database adding 2 new collumns - Active/Deleted and Deleted Date

2) If the first solution isn't feasible, I'd suggest, that the information of the particular deleted user is send in a CSV file to the Admin user who has performed the deletion. This way it is possible to manually add the information to the extracted users list.

I'm actually having this challange right now, as a deleted user is within a log file, is seen accessing a report - and we to tell who this is. (By other manual logging I'm able to identify who it is - but not from the UserID in the log it self)

[evilaliv3]

Thank you @schris-dk

Let's involve other expert users on this topic like @gianlucagilardi and @larrykind

The current user table that you see in the audit log is just and actual representation of the status to monitor on the safety of the configuration. The real audit log, by current design, is represented by the first tab only. In that table we are collecting information about events.

With this introduction in mind my suggestion is that we can store permanently some of the information about users inside the events so that they could be used to perform an audit in case of necessity. What do you consider would be valuable to annotate on creation of a user? I think the username assigned to the user is enough to avoid storing more sensible data like names and emails. What do you all think?

[schris-dk]

If extra info is added to the Audit log, I would suggest the Public Name to be added instead of the username, as we tend to use email address as the user name.

Personally, I’m more in favor of keeping the User information in the Users tab – maybe with only ID, Public name, creation date and deletion date present.

When I present the log to the customers, I usually create a spreadsheet consisting of the audit log with an extra column looking up the user ID in the users sheet and returning the Public name – this gives a better idea of who did what when 😊

[gianlucagilardi]

Trying to be as concise as possible: I understand there are some local compliance requirements, but if we retain some information (personal data) about a user even after the individual is not a user anymore, we must implement a parallel system to purge that information anytime, since other jurisdictions might (are likely to) not have the same legal compliance requirements, so that continued personal data processing of former users might end up lacking of legal basis .

[schris-dk]

I do understand, but I think, that there are similar laws regarding audit legislation across Europe – but anyway – a solution could be, that the information pertaining User ID, User Public name, Creation Date and Deletion date is sent to the admin, who deletes the user. Then it is possible to store these pieces of info locally. This way the information is removed from the server, but can be added to a user list, when creating a log with readable Public Names.

[larrykind]

Hi everyone, I agree to maintain some minimal personal data of the user, but also with a mechanism to wipe that data manually. Same thing should be done with deleted reports in my opinion, adding a motivation for deletion.

[evilaliv3]

Thank you.

With the same concerns already expressed by some of you i suggest we cold safely_

1. just track the username of the user for the moment and load this information in the log "create_user"
2. we can continue for the moment keeping the logs forever (due to the fact that they are important for the system)
3. we can make it possible to configure the data retention of the entire logs (putting a default of 10 years)
4. we can start a discussion on possibly making granular the data retention policy in relation to the type of log

For the moment lets keep this ticket just dealing with point 1 and eventually open other tickets if not already.

I want to point out because it is not clear that currently the real audit log is represented by the first tab of the section audit log. All the other pages shows the actuall real data and these tabs by current evaluations will be probably entirely removed leaving there only the audit log with the addition of some functionalities to inspect logs (by report by user or something else)