[PATCH v3 0/3] 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 v3 3/3] /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/3] 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

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

Em Tue, 8 Oct 2019 00:16:42 +0200 Johan Herland escreveu: > 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

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

>> There is still an open discussion as to whether the strategy used in >> patch #2 to determine the actor and forward it to the event creation, >> is the way we want to go. >> >> >> Have fun! >> ...Johan > > Hi Daniel/Stephen, > > Any news with regards to this patchset? This is a long-waited

Re: [PATCH 1/3] docker: Rely on caching

On 16-10-2019 14:10, Stephen Finucane wrote: > It seems less likely that tox and tox-pyenv will change than our > requirements. Split up the 'RUN' steps so we don't have to reinstall the > former every time the latter change. > > Signed-off-by: Stephen Finucane > --- > tools/docker/Dockerfile |

[PATCH 5/5] REST: Add submission relations

From: Mete Polat View relations or add/update/delete them as a maintainer. Maintainers can only create relations of sumbissions (patches/cover letters) which are part of a project they maintain. New REST API urls: api/relations/ api/relations// Signed-off-by: Mete Polat --- Previously it was

[PATCH 4/5] docs: Add missing series index schema

From: Mete Polat Signed-off-by: Mete Polat --- This one can probably be cherry-picked immediately. docs/api/schemas/latest/patchwork.yaml | 5 + docs/api/schemas/patchwork.j2 | 5 + docs/api/schemas/v1.0/patchwork.yaml | 5 + docs/api/schemas/v1.1/patchwork.yaml | 5

[PATCH 3/5] models, templates: Add sumbission relations

From: Mete Polat Introduces the ability to add relations between submissions. Relations are displayed in the details page of a submission under 'Related'. Related submissions located in another projects can be viewed as well. Signed-off-by: Mete Polat ---

[PATCH 0/5] Add submission relations

From: Mete Polat This patch introduces the ability to view relations between submissions by creating and updating them via the REST API. Changes since v1: - Allow cover letters to be in relations as well (submission relations) - Move from Django permission to a maintainer based one (and update

[PATCH 2/5] ui, templates: Combine series and related row

From: Mete Polat Move the series patch list from 'Related' to 'Series' and display the series name, its patches and a detailed link in the same row. This allows to use the 'Related' row for actually showing submission relations instead. Signed-off-by: Mete Polat --- htdocs/css/style.css

Re: [PATCH] models: Use database constraints to prevent split Series

On Wed, 2019-10-16 at 13:06 +0100, Stephen Finucane wrote: > 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,

[PATCH 3/3] docker: Require GID also

If you don't do this, created files end up with a group of 'gcc' or whatever group has an ID of 1000. Signed-off-by: Stephen Finucane --- docker-compose.yml | 2 ++ tools/docker/Dockerfile | 5 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git docker-compose.yml

[PATCH 1/3] docker: Rely on caching

It seems less likely that tox and tox-pyenv will change than our requirements. Split up the 'RUN' steps so we don't have to reinstall the former every time the latter change. Signed-off-by: Stephen Finucane --- tools/docker/Dockerfile | 9 +++-- 1 file changed, 3 insertions(+), 6

[PATCH 2/3] docker: Ignore .tox, .backups directories

These can be _huge_ which can significantly slow down the startup time. We don't need them so ignore them. Signed-off-by: Stephen Finucane --- .dockerignore | 2 ++ 1 file changed, 2 insertions(+) diff --git .dockerignore .dockerignore index 216f4ba2..77feb067 100644 --- .dockerignore +++

[PATCH] 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