]> git.ipfire.org Git - thirdparty/patchwork.git/commit
Fix issue with delegation of patch via REST API
authorStephen Finucane <stephen@that.guru>
Sat, 21 Sep 2019 18:06:14 +0000 (19:06 +0100)
committerStephen Finucane <stephen@that.guru>
Sat, 21 Sep 2019 18:30:21 +0000 (19:30 +0100)
commitab35df8c33a178b3b2349c1e4727393b94f5e916
tree0a7750e4638e31e0a42a8416a8a99f503a0809a0
parent319b6f9d750c220d47c1044246d4e97fd500c6d4
Fix issue with delegation of patch via REST API

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>
patchwork/api/patch.py
patchwork/tests/api/test_patch.py