summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorStephen Finucane <stephen@that.guru>2019-09-21 19:06:14 +0100
committerStephen Finucane <stephen@that.guru>2019-09-21 19:30:21 +0100
commitab35df8c33a178b3b2349c1e4727393b94f5e916 (patch)
tree0a7750e4638e31e0a42a8416a8a99f503a0809a0 /lib
parent319b6f9d750c220d47c1044246d4e97fd500c6d4 (diff)
downloadpatchwork-ab35df8c33a178b3b2349c1e4727393b94f5e916.tar
patchwork-ab35df8c33a178b3b2349c1e4727393b94f5e916.tar.gz
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>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions