[PATCH v2 2/3] Include the responsible actor in applicable events

[Johan Herland]

On Wed, Oct 9, 2019 at 8:04 AM Daniel Axtens <dja at axtens.net> wrote:
> Johan Herland <johan at herland.net> writes:
> > We want to use the events as an audit log. An important part of this is
> > recording _who_ made the changes that the events represent.
> >
> > To accomplish this, we need to know the current user (aka. request.user)
> > at the point where we create the Event instance. Event creation is
> > currently triggered by signals, but neither the signal handlers, nor the
> > model classes themselves have easy access to request.user.
> >
> > For Patch-based events (patch-created, patch-state-changed,
> > patch-delegated, patch-completed), we can do the following hack:
> > The relevant events are created in signal handlers that are all hooked
> > up to either the pre_save or post_save signals sent by Patch.save().
> > But before calling Patch.save(), Patchwork must naturally query
> > Patch.is_editable() to ascertain whether the patch can in fact be
> > changed by the current user. Thus, we only need a way to communicate
> > the current user from Patch.is_editable() to the signal handlers that
> > create the resulting Events. The Patch object itself is available in
> > both places, so we simply add an ._edited_by attribute to the instance
> > (which fortunately is not detected as a persistent db field by Django).
> >
> > The series-completed event is also triggered by Patch.save(), so uses
> > the same trick as above.
>
> Aren't patch-created and series-completed usually triggered by incoming
> emails also? (like with cover-created)

I'm sure you are right (I'm still finding my way around the code base
and don't know all the sources of these events). In those cases the
'actor' is probably left as NULL (since I suspect is_editable() is
never called before .save()). IMHO this is correct and perfectly fine:
The event simply does not have an 'actor', i.e there is no user that
intentionally caused this thing to happen.

> What happens if you use parsemail or parsearchive to load mail in? Is
> the actor always NULL for patch-created in this case?

I suspect so. Depends on whether parsemail/parsearchive runs with some
kind of request.user set, and if is_editable() is ever called from
that code. Again, the audit log here is (in our view, at least)
primarily there to document a wayward user (or their script)
mistakenly updating patch states and delegates. Recording a non-NULL
actor is only important for events that are triggered manually, not
for events that automatically/naturally arise from incoming emails.

Have fun!
...Johan