[PATCH] Fix issue with delegation of patch via REST API

[Stephen Finucane]

On Sat, 2019-09-21 at 19:30 +0100, Stephen Finucane wrote:
> 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 at that.guru>
> Closes: #313
> Reported-by: Bjorn Helgaas <helgaas at kernel.org>

The test added here failed when the fix is reverted so I'm pretty
confident this is correct. As such, I've gone ahead and applied it and
will cut a v2.1.4 release later today.

Stephen