[PATCH v4 1/4] models.Event: Add the user responsible for the event

This allows using the events as a kind of audit log, to see how a patch came to its current state/delegate. Cc: Mauro Carvalho Chehab Signed-off-by: Johan Herland Reviewed-by: Stephen Finucane --- patchwork/migrations/0037_event_actor.py | 21 + patchwork/models.py

[PATCH v4 0/4] Store the 'actor' responsible for events

The V4L project (https://patchwork.linuxtv.org) uses patch states and delegates extensively to track progress. We want an audit log to keep track of the changes made to these patch fields. The Event model already records this information, but leaves out one crucial detail: which maintainer/user

[PATCH v4 2/4] Include the responsible actor in applicable events

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

[PATCH v4 3/4] /api/events: Add 'actor' field to generated JSON

Cc: Mauro Carvalho Chehab Signed-off-by: Johan Herland Acked-by: Daniel Axtens --- docs/api/schemas/latest/patchwork.yaml | 6 ++ docs/api/schemas/patchwork.j2 | 8 docs/api/schemas/v1.2/patchwork.yaml | 6 ++ docs/usage/overview.rst| 3 +++

[PATCH v3 2/2] parser: Use a second query to weed out duplicate series

Annoyingly, not all email clients properly thread emails using the message ID fields originally specified in RFC 822 [1]. Worse, some MTAs (cough, outlook.com, cough) actually override what the client configures, breaking the world in the process. Realising this is an issue, Patchwork supports

[PATCH v3 1/2] models: Use database constraints to prevent split Series

Currently, the 'SeriesReference' object has a unique constraint on the two fields it has, 'series', which is a foreign key to 'Series', and 'msgid'. This is the wrong constraint. What we actually want to enforce is that a patch, cover letter or comment is referenced by a single series, or rather a

Re: [PATCH v3 3/3] /api/events: Add 'actor' field to generated JSON

On Thu, 2019-10-17 at 00:44 +0200, Johan Herland wrote: > Cc: Mauro Carvalho Chehab > Signed-off-by: Johan Herland > Acked-by: Daniel Axtens This looks good to me. Since you're respinning though, have you considered adding the ability to filter events by actor? I don't see it here and I think

Re: [PATCH v3 2/3] Include the responsible actor in applicable events

On Thu, 2019-11-14 at 23:37 +0100, Johan Herland wrote: > On Thu, Nov 14, 2019 at 6:31 AM Andrew Donnellan wrote: > > 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

Re: [PATCH v3 0/3] Store the 'actor' responsible for events

On Mon, 2019-11-11 at 19:30 +0100, Johan Herland wrote: > On Fri, Oct 18, 2019 at 8:29 AM Daniel Axtens wrote: > > Johan Herland writes: > > > > > The V4L project (https://patchwork.linuxtv.org) uses patch states and > > > delegates extensively to track progress. We want an audit log to keep >

Re: [PATCH v3 0/5] Add submission relations

On Sun, 2019-10-20 at 20:57 +0200, Mete Polat wrote: > This patch introduces the ability to view relations between submissions by > creating and updating them via the REST API. > > Changes since v2 (note: forgot to mark the previous revision as v2) > - Replace a mistakenly placed tab intention in

Re: [PATCH] Allow ordering events by date

On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: > By default, the events API orders events by date in descending order > (newest first). However, it's useful to be able to order the events by > oldest events first. For example, when a client is polling the events > API for new events since

Re: [PATCH] REST: Exclude filters added in later version

On Sat, 2019-11-30 at 16:40 +, Stephen Finucane wrote: > If a person requests API version 1.1, they should get the exact same > behavior regardless of the base Patchwork version. We already do this > for fields in the output, so now extend this to filters in the > querystring. > >

[PATCH] REST: Exclude filters added in later version

If a person requests API version 1.1, they should get the exact same behavior regardless of the base Patchwork version. We already do this for fields in the output, so now extend this to filters in the querystring. Signed-off-by: Stephen Finucane Cc: Daniel Axtens --- patchwork/api/filters.py

Re: [PATCH] docs: Fix note about the required Postfix rights

On Tue, 2019-10-29 at 08:08 +, Ali Alnubani wrote: > Hi Daniel, > > > -Original Message- > > From: Daniel Axtens > > Sent: Tuesday, October 29, 2019 8:06 AM > > To: Ali Alnubani ; patchwork@lists.ozlabs.org > > Cc: Thomas Monjalon > > Subject: Re: [PATCH] docs: Fix note about the

Re: [PATCH] Disable i18n machinery, use correct locale

On Wed, 2019-11-06 at 14:53 +0800, Stephen Finucane wrote: > Two issues here. Firstly, the use of the 'USE_I18N'. The Django docs > describe this as such: > > A boolean that specifies whether Django’s translation system should > be enabled. This provides an easy way to turn it off, for

Re: [PATCH v2] Improve pull request URL matching regex

On Sat, 2019-11-16 at 11:16 -0500, Konstantin Ryabitsev wrote: > When git-request-pull output is pasted into a mail client instead of > mailed directly, the ref part of the pull URL may end up wrapped to the > next line. > > Example: >