lp:patchwork

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1644. By Stephen Finucane <email address hidden> on 2019-12-01

requirements: Add pyup markers to prevent dumb PRs

Until [1] is merged, we're going to have to override what these markers
are doing. Perhaps it would be easier to just specify the markers in the
comments as the actual marker, but I like using pip's features and the
comments *should* be temporary.

[1] https://github.com/pyupio/pyup/pull/367

Signed-off-by: Stephen Finucane <email address hidden>

1643. By Stephen Finucane <email address hidden> on 2019-12-01

docs: Change category of API release note

Signed-off-by: Stephen Finucane <email address hidden>

1642. By Stephen Finucane <email address hidden> on 2019-12-01

docs: Correct location of release note

Not sure how this ended up here but we both missed this. Correct the
location.

Signed-off-by: Stephen Finucane <email address hidden>
Fixes: d380219e ("api: support filtering patches by hash")

1641. By Stephen Finucane <email address hidden> on 2019-12-01

docs: Add release notes for recently added features

Signed-off-by: Stephen Finucane <email address hidden>

1640. By Johan Herland <email address hidden> on 2019-12-01

REST: Add 'actor' field to '/events' model

Signed-off-by: Johan Herland <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>
Acked-by: Daniel Axtens <email address hidden>
Cc: Mauro Carvalho Chehab <email address hidden>
Closes: #73

1639. By Johan Herland <email address hidden> on 2019-12-01

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 signals, but neither the signal handlers, nor the
model classes themselves have easy access to request.user.

For some Patch-based events (patch-state-changed, patch-delegated), 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).

For the check-created event the current user always happens to be the
same as the 'user' field recorded in the Check object itself.

For the other Patch-based events (patch-created, patch-completed, and
series-completed), although they are also triggered by Patch.save(),
they are triggered as a result of incoming emails, hence have no real
actor as such, so we simply leave the actor as None/NULL. The same
argument also applies to the cover-created and series-created events.

Signed-off-by: Johan Herland <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>
Cc: Mauro Carvalho Chehab <email address hidden>

1638. By Johan Herland <email address hidden> on 2019-12-01

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.

Signed-off-by: Johan Herland <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>
Cc: Mauro Carvalho Chehab <email address hidden>

1637. By Stephen Finucane <email address hidden> on 2019-11-30

templates: Use 'en' locale

As discussed at [1], the UI was originally written in Australian English
but as it's been through a couple of pairs of hands since the chances
are things are more than a little messed up. Just use 'en' as our locale
rather than 'en-US', 'en-AU' or anything else.

[1] https://lists.ozlabs.org/pipermail/patchwork/2019-November/006342.html

Signed-off-by: Stephen Finucane <email address hidden>
Suggested-by: Daniel Axtens <email address hidden>

1636. By Stephen Finucane <email address hidden> on 2019-11-30

docs: Only include 'order' filter in '/events/' for v1.2+

Even though we don't actually version this thing, don't document for
older versions of the API lest people using older deployments get
confused.

Signed-off-by: Stephen Finucane <email address hidden>

1635. By Jeremy Cline <email address hidden> on 2019-11-30

Allow ordering events by date

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 a given date and wishes to process them in
chronological order.

Signed-off-by: Jeremy Cline <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>