Add audit log for debugging #302
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tijmenb
force-pushed
the
add-papertrail
branch
from
5b94b39
to
68e3fb0
Compare
|
Just to understand the context, Is this intended entirely for debugging purposes or are they any ideas about it's usage with regards to rolling back? It seems a cool idea and I can see it being useful in the early days. I have a concern that if we're not looking at it often it could fill up a lot of data. What sort of future do you see for this with the context of storing revisions? |
|
@kevindew argh, tried to communicate that in the PR description but it wasn't clear enough. Papertrail should only be used as an audit log, and absolutely nothing else. This will make it easy for us to throw away the data and have a functioning application. |
|
Can you add comment above the Papertrail lines to indicate what it's being used for. I reckon when we eventually have two kinds of history it'll confuse people unless we clearly signpost it for them. |
tijmenb
force-pushed
the
add-papertrail
branch
from
3bbc50d
to
89658fb
Compare
tijmenb
force-pushed
the
add-papertrail
branch
from
89658fb
to
d19b0e9
Compare
tijmenb
force-pushed
the
add-papertrail
branch
from
d19b0e9
to
713accb
Compare
This adds the papertrail gem to the app and sets it up. Paperclip will keep track of all of the changes in the models (Document, Image, User). The reason for this is to keep an audit log of all of the changes. While we're busy building this application, we're very likely to run into a situation where a document has entered a particular state, and we're not sure how this happened. Having a full log of changes will help us a lot in debugging. And with time being linear, we won't be able to add this feature retroactively if something goes wrong. It's worth noting that this is a distinct & separate use case from the history timeline (#270), which is a feature designed for end-users. The two shouldn't be coupled. Downside of having this: - It slow all of the writes down. When a document is edited, there will be multiple versions created because of the state changes. - The versions table is likely to grow a lot. We'll need to make sure that we clean up if the table becomes too large. There's a ticket on the planning board for this: https://trello.com/c/XMrIPU88. This is also the reason that we need to keep the history feature and this audit trail separate, because we should be able to truncate the table without losing end-user functionality.
This makes it easier to add things to it.
This displays the audit log for internal users. - We have to cache the users from the timeline to prevent a N+1 query, since the `whodunnit` isn't a normal Rails relationship - Because `updated_at` is always the same as the event's `created_at`, we won't have to display it.
This test inadvertently passed because the internal metadata component showed "major", even if the page itself does not.
tijmenb
force-pushed
the
add-papertrail
branch
from
713accb
to
eb5ef97
Compare
kevindew
approved these changes
Sep 21, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the papertrail gem to the app and sets it up. Paperclip will keep track of all of the changes in the models (Document, Image, User).
The reason for this is to keep an audit log of all of the changes. While we're busy building this application, we're very likely to run into a situation where a document has entered a particular state, and we're not sure how this happened. Having a full log of changes will help us a lot in debugging. And with time being linear, we won't be able to add this feature retroactively if something goes wrong.
It's worth noting that this is a distinct & separate use case from the history timeline (#270), which is a feature designed for end-users. The two shouldn't be coupled.
Downside of having this:
This PR also adds the entries to a document "debug" page.