kobotoolbox / kpi / 12691298492

81%

master: 76%

push

github

feat(projectHistoryLog): record submission modifications (#5404)


### 📣 Summary
Log updates to submissions, both content and validation status.

### 💭 Notes

#### SubmissionUpdate

The `SubmissionUpdate` class is just a dataclass meant to make it clear
what information we need to create a PH log for submission
modification/creation/deletion. It's meant mostly to help future
developers since we're not using the usual `initial_data`/`updated_data`
pattern where we just take configured fields off of a model.

#### ProjectHistoryLog.__init__
 
This PR includes a small refactor on ProjectHistoryLog to set the
`app_name`, `model_name`, and `log_type` in the `__init__` method like
we do with `create`. This saves us some repeated code when we are
creating logs in bulk.

#### Attaching the asset to the request

We always need the `asset_uid` when logging any views that include the
`AssetNestedObjectViewsetMixin` mixin, so I updated `AuditLoggedViewSet`
to always attach the asset (available via the mixin) to the request. We
may be able to use this to simplify other code later if we wish.

#### Where we add data to the request

We can't use the usual method of having the views inherit from
`AuditLoggedViewSet` and configuring `logged_fields` on the relevant
model because the viewsets that update Instances rarely act directly on
the Instance objects via get_object or the serializers. Instead they
usually have custom code that works through the deployment object on the
asset.

We could pass the request from the viewset through the layers of other
methods until we get to the part where we are actually updating
instances, but this would require a lot of changes in existing view code
and we're trying to keep the audit log code relatively self-contained.
Changes to logging code should ideally not require changes in view code.
Instead, I decided to use a receiver on the Instance model `post_save`
signal.

This also should allow the code to be more backend-agnostic sin... (continued)

5811 of 9300 branches covered (62.48%)

59 of 60 new or added lines in 7 files covered. (98.33%)

22216 of 27598 relevant lines covered (80.5%)

0.8 hits per line