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

Bjorn Helgaas helgaas at kernel.org
Tue Sep 24 06:23:42 AEST 2019

[+cc Jeremy, Michael]

On Sat, Sep 21, 2019 at 07:30:46PM +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.

Thanks a lot for fixing this so fast.

I don't know who runs patchwork.ozlabs.org, maybe Jeremy or Michael
has a pointer?  And I don't know if/when your fix might show up in
that instance.  It sounds like maybe there's a possibility of a manual
server-side workaround in the meantime, i.e., creating a UserProfile
matching my User?

Or maybe a more involved client-side workaround that uses whatever
path http://patchwork.ozlabs.org/ uses for delegation?

More information about the Patchwork mailing list