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

[Stephen Finucane]

On Tue, 2019-09-24 at 10:10 +0100, Stephen Finucane wrote:
> 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.

v2.1.5 (!) has been released. Just got to get ozlabs up-to-speed now.

Stephen