OSIDB-2269: implement history on Flaw, Affects and FlawMeta #483
Conversation
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
2 times, most recently
from
4b4b479
to
9161aa7
Compare
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
from
9161aa7
to
6102170
Compare
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
10 times, most recently
from
4f9cfbc
to
9aee160
Compare
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
11 times, most recently
from
4967e49
to
2e18343
Compare
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
13 times, most recently
from
b73d2e2
to
f69d318
Compare
JimFuller-RedHat
force-pushed
the
audit-history-feature
branch
from
f69d318
to
effe283
Compare
| pghistory.InsertEvent(), | ||
| pghistory.UpdateEvent(), | ||
| pghistory.DeleteEvent(), | ||
| exclude="local_updated_dt,meta_attr,_alerts", |
There was a problem hiding this comment.
The _alerts attribute will unfortunately soon cause some conflict as Daniel is just reworking it into a proper model. That future model can also be excluded from the history as we can recreate the alerts if needed.
There was a problem hiding this comment.
ah thx for the headsup!
| pghistory.DeleteEvent(), | ||
| exclude="meta_attr,_alerts", | ||
| model_name="FlawMetaAudit", | ||
| ) |
There was a problem hiding this comment.
FlawMeta is a relic model and a subject for a removal (with the next major release). All of its parts were already migrated into other places (like FlawReference etc.). You can simply exclude it from the audit.
There was a problem hiding this comment.
ya I wondered, thx ... will remove ... I will reach out to u to discuss if any other models need the treatment
| @@ -890,6 +972,7 @@ class Meta: | |||
| + ACLMixinSerializer.Meta.fields | |||
| + AlertMixinSerializer.Meta.fields | |||
| + TrackingMixinSerializer.Meta.fields | |||
| + HistoryMixinSerializer.Meta.fields | |||
There was a problem hiding this comment.
nitpick: I am sure that it is not always possible but when it is I would prefer ordering the list-like structures alphabetically so a human can easily see what is there and what is not
| def test_flawevent(self): | ||
| """ """ | ||
| # create a flaw with an affect | ||
| Flaw.objects.all().delete() |
There was a problem hiding this comment.
I wonder why the flaws are deleted first. Looking at the event count later it seems that it generates no event so I guess it has no effect - which is what I would assume at the beginning of a test (no flaws present).
| include_history_param = None | ||
| # Get include history from request | ||
| if request: | ||
| include_history_param = request.query_params.get("include_history") |
There was a problem hiding this comment.
Suggestion: You might want to describe this query parameter in OpenAPI schema the same way as we did with the include_fields or exclude_fields, see api_views.py for that.
| if include_history_param is None: | ||
| self.fields.pop("history", None) |
There was a problem hiding this comment.
Putting basically include_fields=<anything> will surface the history?
This PR implements the audit history tracking feature ... and surfaces up a history key on flaws, affects and flawmeta in REST API.
By default history is not included and one must use the include_history url param to enable:
In addition added a primitive audit endpoint which lists all events:
NOTE - The next PR will contain django migration for batch loading all BZ historical data into these new event tables as well as remove some older event related cruft. There is no point running this migration in stage (as stage has no data).