| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
Not sure how this ended up here but we both missed this. Correct the
location.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: d380219e ("api: support filtering patches by hash")
|
|
|
|
| |
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Johan Herland <johan@herland.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
Acked-by: Daniel Axtens <dja@axtens.net>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Closes: #73
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <johan@herland.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
|
|
|
|
|
|
|
| |
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 <johan@herland.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
Suggested-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
| |
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 <jcline@redhat.com>
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
Cc: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a feature that the XML-RPC API has, and which is used in
the wild [1], so support it in the REST API.
I tried to version the new filter field, but it's not at all clear
how to do this with django-filters. The best way I could find
requires manually manipulating request.GET, which seems to defeat
the point of django-filters. So document it for 1.2, and have it
work on older versions as an undocumented feature.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-patchwork-bot.py?id=104e7374e1be8458e6d2e82478625a7bf8c822ff
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
|
|
|
| |
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: 8c229caa ("Improve pull request URL matching regex")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The permissions for the user running the postfix process are
not the ones used for external file or command delivery by default.
The ones defined by default_privs are (in case the aliases(5) file
that is owned by root was being used). A privileged user or the
postfix owner should not be used in this case.
See http://www.postfix.org/postconf.5.html#default_privs and
local(8).
Signed-off-by: Ali Alnubani <alialnu@mellanox.com>
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 performance.
If this is set to False, Django will make some optimizations so as not
to load the translation machinery.
We don't do translations and won't until such a time as someone comes
asking for them. Optimize things accordingly by setting 'USE_I18N' to
False and removing the now-unnecessary 'LANGUAGE_CODE' setting.
Secondly, the use of en-AU is a bit of a lie since our UI is actually
written in US English (or should be). The primary reason for a lang tag
to be present is to assist screenreaders and other accessibility tools,
so make their lives easier by reflecting the truth.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: https://lore.kernel.org/r/294422a4-37b2-def5-5d32-8988f27c3a5b@gmail.com/
This change properly parses URLs both with and without newlines.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
|
|
|
|
|
| |
Reviewed-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
| |
We're not doing a good job of it, the versions are out of date and
we keep forgetting to update the README. We are a bit better at
making release notes, so just point people there.
Reviewed-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The .env setup didn't do GID. It's a bit of a chore to do because
there doesn't seem to be a GID shell variable and because we need
to do a bit more work to get a multi-line thing, but this should
work.
While we're at it, change the docker-compose info, it's hopelessly
out of date.
Reviewed-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
| |
This reverts commit f09bfd460814d7125437b0b45a183a221692584a.
|
|
|
|
|
|
|
| |
It's no longer supported upstream, per
https://www.djangoproject.com/download/#supported-versions
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
| |
Specifying language in the <html> tag is recommended in HTML5.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
| |
In HTML5, the type attribute of a script tag is optional if it's
JavaScript.
Remove all occurrences. The only real gain is slightly smaller page output,
but it also shuts up validators that like to be noisy about this.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
It's not valid to put a <div> inside an <h1>. Move the download buttons in
the submission template outside the <h1> tag.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
Prevents table header labels from moving up and down when hiding or
showing additional information for a patch.
Signed-off-by: Mete Polat <metepolat2000@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
The old format redirects to a nonexistent page when
there are multiple versions of the docs.
Signed-off-by: Ali Alnubani <alialnu@mellanox.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
| |
There's a </td> rather than </th> in the bundle list. Fix it.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
| |
There was a series on linuxppc today that was spread over ~13 mins,
so the last two patches were put into a new series.
Extend the time window to 20 mins, and attempt to document it.
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Travis calls `tox -e coverage` unconditionally. However,
the environment has py27 basepython, so all the runs only generate
py27 coverage!
Rather than try to untangle that, just run the coverage when run
in a py27 travis environment. This makes things faster for no
loss of coverage. It means that codecov has nothing to submit for
the py3x environments, but that's no real loss: it would otherwise
submit lots of duplicate data.
We could try to improve coverage by running coverage for 27 and 3x,
but given that 27 is going away, don't stress at this point.
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
landsape.io is down and seems to have been for some time.
The issue tracker [1] doesn't seem to have anything since April.
Pull out the broken badge. If landscape.io returns we can add it
back later.
[1] https://github.com/landscapeio/landscape-issues/issues?q=is%3Aopen+is%3Aissue
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In e017f69376da ("travis: run pep8/flake8 tests"), codecov
was removed from the install step, on the basis that tox-travis
would pull it in automatically.
This, it turns out, isn't entirely true: it is pulled in to the
tox environment, but the data is actually sent in an after_success
step. That is outside the tox environment, as it should be - if it
were part of the tox environment, running `tox -e coverage` on a
developer laptop would try to send data to the web. But, as codecov
now isn't present outside the tox environment, we see in the logs:
$ codecov
codecov: command not found
We don't get any reporting of success/failure in the after_success
step, so we didn't notice.
Restore the installation in the travis environment.
Fixes: e017f69376da ("travis: run pep8/flake8 tests")
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
We just need to mirror the changes in the MySQL/default
docker-compose.yml file.
Fixes: b4f4c8554c11 ("docker: Require GID also")
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
| |
An embarassing miss when applying the previous patch.
Fixes: 681609f9511c ("Python 3.8 support")
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
| |
Enable Python 3.8 in our tests and list it as a supported version.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
| |
It's 2019. It's almost 2020, in fact!
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
Snowpatch is one of the few publically visible API clients.
Document it in the clients list.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
| |
The test_patchwork_from_header test claims to test for the presence of the
X-Patchwork-From header, when we actually call it X-Patchwork-Submitter.
Fix it.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
[dja: fix commit message]
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid triggering spam filters due to failed signature validation, many
mailing lists mangle the From header to change the From address to be the
address of the list, typically where the sender's domain has a strict DMARC
policy enabled.
In this case, we should try to unmangle the From header.
Add support for using the X-Original-From or Reply-To headers, as used by
Google Groups and Mailman respectively, to unmangle the From header when
necessary and associate the patch with the correct submitter based on the
unmangled email address.
When downloading mboxes, rewrite the From header using the unmangled
address, and preserve the original header as X-Patchwork-Original-From in
case someone needs it for some reason. The original From header will still
be stored in the database and exposed via the API, as we want to keep
messages as close to the original received format as possible.
Closes: #64 ("Incorrect submitter when using googlegroups")
Reported-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Tested-by: Daniel Axtens <dja@axtens.net> # mailman only
[dja: add release note]
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
| |
Allow users to create a new bundle, change the name, public flag and
patches of an existing bundle, and delete an existing bundle.
Some small nits with existing tests are resolved.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Closes: #316
|
|
|
|
|
|
| |
We're going to use this functionality elsewhere shortly.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The random module uses the Mersenne Twister pseudorandom number
generator and is not a cryptographically secure random number
generator[0]. The secrets[1] module is intended for generating
cryptographically strong random numbers, so recommend using that to
generate the secret key. It's new in Python 3, so if it's unavailable
fall back to using the ``os.urandom()`` backed implementation of random.
NOTE(stephenfin): Modified to include change to 'config.yaml'. Also
renamed reno to just stick with hyphens for filenames.
[0] https://docs.python.org/3/library/random.html
[1] https://docs.python.org/3/library/secrets.html
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
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 <stephen@that.guru>
|
|
|
|
|
|
| |
A small Python 3 issue is resolved.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
| |
This was also missed when moving pwclient to a separate repo. Fix it now.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: 90e85f9d ("Remove pwclient")
|
|
|
|
|
|
|
| |
This was missed when moving pwclient to a separate repo. Fix it now.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: 90e85f9d ("Remove pwclient")
|
|
|
|
|
|
| |
Explain what it is and why you should use it.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
Helps me avoid simple style issues. We explicitly disable newline checks
for some files where the "fix" would be harmful (e.g. mboxes and
templates).
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
| |
An assortment of fixes identified through the integration of pre-commit.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Migrate our URL schema as follows:
Patches: /project/<linkname>/patch/<msgid>/
Cover Letters: /project/<linkname>/cover/<msgid>/
The usual sub-resources (mbox, raw) hang off those URLs.
The old style URLs (/patch/NNN/*, /cover/NNN/*) redirect appropriately.
I haven't attempted to do anything meaningful with series, and I
have dropped any attempt to provide a generic message-id lookup
or search functionality. One step at a time.
Our database still stores message ids as with angle brackets; we
just work around that rather than trying to migrate. That too can
come later if we think the pain is justified.
Partially-closes: #106
Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Reported-by-but-I-don't-want-to-spam: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There have been reports of people being unable to delegate patches to
themselves, despite being a maintainer or the project to which the patch
is associated.
The issue is a result of how we do a check for whether the user is a
maintainer of the patch's project [1]. This check is checking if a given
'User.id' is in the list of items referenced by
'Project.maintainer_project'. However, 'Project.maintainer_project' is a
backref to 'UserProfile.maintainer_projects'. This means we're comparing
'User.id' and 'UserProfile.id'. Boo.
This wasn't seen in testing since we've had a post-save callback [2] for some
time that ensures we always create a 'UserProfile' object whenever we create a
'User' object. This also means we won't have an issue on deployments initially
deployed after that post-save callback was added, a 'User' with id=N will
always have a corresponding 'UserProfile' with id=N. However, that's not true
for older deployments such as the ozlabs.org one.
[1] https://github.com/getpatchwork/patchwork/blob/89c924f9bc/patchwork/api/patch.py#L108-L111
[2] https://github.com/getpatchwork/patchwork/blob/89c924f9bc/patchwork/models.py#L204-L210
Signed-off-by: Stephen Finucane <stephen@that.guru>
Closes: #313
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
|