feat: add support for audit log

[djaiss]

This PR adds the concept of audit logs.

An audit log is a message explaining what a user did by using the application.

For instance, when creating a new contact, an audit log would be created that would log User X has created contact Y. This is useful for two important points:

• security purposes: first of all, when an account has multiple users, this ensures that everything is logged in the account and you can always check in the account to see who has done what when.
• information sharing: when logging everything, we can display on the dashboard an history of important actions in the account. This is useful in the case of an account with one user or multiple users: it’s always interesting to remember what you did just by looking at the dashboard.

We will display logs in three places:

• an audit log on the settings page, listing all the actions users have done in the account
• on the dashboard, highlighting the most important actions,
• on a contact page, to understand who's done what on the contact.

For the scope of this PR, I've only added one action: creating a contact. Once it’s merged, we'll be able to do it for all the other actions.

How it works:

It’s simple. We have a new model called AuditLog, which contains

• the account id,
• the author id and the author name. The author is the User object of the person who've done the action. Why do we need both? Well, if we remove a user from the account, the User object will be deleted, therefore we won't have access to the name. By storing it while the action happened, we can know who it was.
• the action (like contact_created). This will be used to generate the right sentence that will explain what the user did
• a json object (stored as an array cause mysql sucks with json): this represents the different parameters that the action needs to be correctly described. For instance, when creating an account, we can use it to store the name and the id of the contact that was created.

Audit logs are created inside Services. You need to call the job called LogAccountAudit and dispatch it. This job in itself does nothing - it just calls a new service that will handle all the heavy load: LogAccountAction which actually creates the audit log.

The only drawback is that we need to add a new parameter when calling a service: author_id, which is actually the id of the user who does the action. We have to, otherwise we won't know who did the action. This will require that we change most of the current services to support this. I've done it for the CreateContact service in the scope of this PR.

To display an audit log, we need to "process" it, as we store a key (the action) and a JSON to describe it. This is the responsability of the AuditLogHelper, a new helper that takes those two and translates them in a human readable sentence.

How to use

For every service, we simply need to dispatch the LogAccountAudit job with the right parameters and that's it. It’s really simple, and everything will be taken care of.

In the Settings page:

In the Contact new History tab:

Checklist

• Screenshots are included if the PR changes the UI.
• The API has been updated.
• API's documentation has been added by submitting a pull request in the marketing website repository.
• Tests have been added for the new code.
• If you change a model, make sure the FakeContentTableSeeder is updated. We need seeders to develop locally and generate fake data.
• Make sure exporting account data as SQL is still working.
• Make sure your changes do not break importing data with vCard and .csv files.
• Make sure account reset and deletion still work.
• CHANGELOG entry added, if necessary, under UNRELEASED.
• If it's relevant and worth mentioning, create a changelog entry for this change. The changelog entry will appear inside the UI for all users to see. To know if your change is worth the creation of a changelog entry, read the documentation.

[djaiss]

@asbiin the code is not ready to review yet, but please read the description, and let me know what you think.

[djaiss]

@asbiin ready for review!

[djaiss]

Alright so I still need to add tests for the controllers. But the rest of the code is ready for review. Sorry for the size of this PR.

[djaiss]

@asbiin ready!

[asbiin]

Just some little changes

[asbiin]

That's really great!
So we can add LogAccountAudit::dispatch everywhere it's usefull to log something?

[djaiss]

So we can add LogAccountAudit::dispatch everywhere it's usefull to log something?

Exactly. Simply dispatch the job with the proper payload and that's it.

[djaiss]

@asbiin The API documentation also has been written in the marketing website.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

86.6% Coverage
0.1% Duplication

[github-actions]

This pull request has been automatically locked since there
has not been any recent activity after it was closed.
Please open a new issue for related bugs.