lp:patchwork

Created by Jeremy Kerr on 2015-11-06 and last modified on 2019-12-01
Get this branch:
bzr branch lp:patchwork

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Patchwork Devs
Project:
Patchwork
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at https://github.com/getpatchwork/patchwork.git.

The next import is scheduled to run in 4 hours.

Last successful import was 1 hour ago.

Import started 1 hour ago on alnitak and finished 1 hour ago taking 20 seconds — see the log
Import started 7 hours ago on alnitak and finished 7 hours ago taking 20 seconds — see the log
Import started 13 hours ago on izar and finished 13 hours ago taking 20 seconds — see the log
Import started 20 hours ago on alnitak and finished 19 hours ago taking 20 seconds — see the log
Import started on 2019-12-04 on alnitak and finished on 2019-12-04 taking 20 seconds — see the log
Import started on 2019-12-04 on izar and finished on 2019-12-04 taking 25 seconds — see the log
Import started on 2019-12-04 on alnitak and finished on 2019-12-04 taking 20 seconds — see the log
Import started on 2019-12-03 on izar and finished on 2019-12-03 taking 20 seconds — see the log
Import started on 2019-12-03 on alnitak and finished on 2019-12-03 taking 20 seconds — see the log
Import started on 2019-12-03 on alnitak and finished on 2019-12-03 taking 25 seconds — see the log

Recent revisions

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>

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers