Log all actions for admins-MVP

[mrcasals]

This is a Feature Proposal

🎩 Description

In order to improve control on what other admins are doing, we want all actions done by admins to be logged and shown in a log feed in the admin section.

For each action, we want to see:

• user who performed the action
• date and time of the action performed
• the URL where the change was made
• if applicable, the field that has been modified and the previous and the new value

We also need to decide if this info is only accessible for organization admins, or space admins can view this too. Update: on #2611 it was decided to start showing the admin logs only to organization admins.

This issue needs design. Design has been provided and accepted by @decidim/product.

📌 Related issues

• Log all changes in entities (models) #918
• Define if the admin log has to be public or just for admins. #2611
• EPIC: Activity log for administrators, moderators and verifiers #2718 (EPIC)

🔨 Related PR

• Add admin logs codebase #2604

[mrcasals]

@decidim/product I have a few questions about this that were not answered in the last meeting.

We need to decide (heh) who has access to this log. For simplicity, I'll start working on this considering only organization admins have access to this. I think allowing space admins to see this log raises a question: should space admins see data only for their assigned spaces, o should they see everything? Since controlling this is much harder, I'll ignore this until you guys decide what to do.

What happens when the resource of a given action is deleted? Should we remove all actions related to that resource, or should we keep showing them somehow?

Just to be sure, the modified fields will only be shown when an admin updates a resource, not when they create it. Is that OK?

And, again, I will need design for this.

[mrcasals]

I'm thinking about showing this text for each action:

%{user name} %{action} %{resource title} (%{resource type}) in %{space title} (%{space type})

Space title and resource title would be links to the resources. User name could be a link too. An example of text, with the variables set, could be:

Jane Austen (@janeausten) created "Regular meetup" (meeting) in "Book Cycle" (participatory process)

Thoughts?

[arnaumonty]

We need to decide (heh) who has access to this log. For simplicity, I'll start working on this considering only organization admins have access to this. I think allowing space admins to see this log raises a question: should space admins see data only for their assigned spaces, o should they see everything? Since controlling this is much harder, I'll ignore this until you guys decide what to do.

For a moment I would say just give access to organization admins, not space admins.

What happens when the resource of a given action is deleted? Should we remove all actions related to that resource, or should we keep showing them somehow?

We should keep showing the previous actions.

Just to be sure, the modified fields will only be shown when an admin updates a resource, not when they create it. Is that OK?

Ok

And, again, I will need design for this.

Sure. We should involve @decidim/lot-px here. Just to clarify this page should be shown on the main page of admin board but we have to take into account that in this page-board in a soon future we will add other statistics of decidim.

%{user role} %{user name} %{action} %{resource title} (%{resource type}) in %{space title} (%{space type})

I miss the date of the action. I will put first user name and then user role.

[mrcasals]

@arnaumonty perfect, thanks!

[mrcasals]

A thing to consider: I can only control what the components in this repo do. Actions performed by admins in external components won't appear in the admin log unless they apply the same changes I'm doing.

If I didn't have to track what fields have changed and who has performed the action, then I could do this mostly automatically, I guess, but since I need to save this data I cannot do it magically, and some changes need to be applied.

I think it's something @decidim/product needs to be aware of, just in case.

[mrcasals]

Ah, also: tracking all this data will create a lot of records in the database (a couple of database rows per action).

[mrcasals]

@decidim/product just as with notifications, this has to be an EPIC, since I have to manually log the actions, for each component and resource.