feat: audit additional events #2918
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
github-actions
bot
added
front-end
Uffizzi Ephemeral Environment
|
There was a problem hiding this comment.
@riceyrice on the whole, this looks great! I've added some (mostly) minor comments, but it seems to achieve what we're looking for and the code looks good.
api/audit/tasks.py
Outdated
| environment=feature_state._get_environment(), | ||
| project=feature_state._get_project(), |
There was a problem hiding this comment.
These methods should be 'public' if we're calling them here. Is there a reason they're 'private'?
There was a problem hiding this comment.
They are only private because they were already private - I guess they were intended for use by the public get_environment_and_project (now get_organisations_project_environment).
Previously this code accessed member variables directly, which seemed to be against DRY and introduce the possibility that it could pick different values to those used for audit logs that go via _get_environment.
I guess there are some options here:
- use
get_organisations_project_environmentpublic interface (likecreate_audit_log_from_historical_recordin the same file does) - make
_get_organisations/project/environmentinto public interface
There was a problem hiding this comment.
I guess the downside of option 1 here is that we don't need the organisations (I don't think?). My preference in that case would be option 2 but if, for whatever reason, we do want the organisation here too, let's go with option 1.
There was a problem hiding this comment.
We don't need organisation so went with option 2
api/core/models.py
Outdated
| Base.related_object_type = related_object_type | ||
| if audit_create: | ||
| Base.get_create_log_message = default_get_create_log_message | ||
| if audit_update: | ||
| Base.get_update_log_message = default_get_update_log_message | ||
| if audit_delete: | ||
| Base.get_delete_log_message = default_get_delete_log_message |
There was a problem hiding this comment.
What's the benefit of doing it this way versus defining the defaults on the base class itself?
There was a problem hiding this comment.
This dance was to avoid changing the default behaviour of abstract_base_auditable_model_factory as many things already call this expecting _AbstractBaseAuditableModel and its implementations that return None, logging nothing by default.
All the things I've added want to log create/update/delete by default (except project but maybe it should).
I will see if I can do it more elegantly using mixins.
There was a problem hiding this comment.
I've replaced this with a mixin implementation - it's a bit verbose but hopefully clearer. tbh if create/update/delete logging could be on/off rather than three toggles, that could be a fair bit simpler. Project audit being create/delete only is the only real reason for it and maybe that's not a real requirement.
There was a problem hiding this comment.
Yeah, I don't think that's an intentional requirement. I think having project update would also be beneficial.
# Conflicts: # api/poetry.lock
Thanks for submitting a PR! Please check the boxes below:
pre-committo check lintingChanges
Implements #2797
AuditLogto associate with organisation without needing project/environmentNote:
python manage.py populate_history --automust be run after migrations in order to create initial history instances, otherwise the first update to any model will log a warning but create no audit log records.Note: There are corresponding changes in flagsmith-saml to ensure django signals are sent which must be deployed to correctly audit saml login success/failure.
Note: Does not include front-end changes to view per-organisation audit logs.
AuditLogviews look for organisation directly/indirectly and should be simplified once organisation field is backfilled for existing records.How did you test this code?
Tested manually by making changes to memberships and permissions in the front end app or django admin or django shell. Audit log may be inspected per-project or per-environment in the front end but otherwise must be checked using REST API for per-organisation feed or django shell.
Unit tests will be added once functionality approved. Existing unit tests may fail as I'm currently unable to run them 😞Login success/failure tested manually in front end using samltest.id and developer GitHib/Google apps.
Unit tests now complete.