On 17/10/19 9:44 am, Johan Herland wrote:
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.
For the check-created event the current user always happens to be the
same as the .user field recorded in the Check object itself.
The remaining events (cover-created, series-created) are both triggered
by incoming emails, hence have no real actor as such, so we simply leave
the actor as None/NULL.
How is cover-created different from patch-created?
The rest of this seems reasonable.
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
