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

Stephen Finucane stephen at that.guru
Tue Sep 24 18:51:53 AEST 2019

On Mon, 2019-09-23 at 15:23 -0500, Bjorn Helgaas wrote:
> [+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?

That won't work because you'd have to modify UserProfile.id to match
the corresponding User.id for every entry. Definitely not worth it.

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

I've been considering that but the problem is we don't expose user
profile information via the API. This makes sense because the fields on
the user profile are not something you'd need/want to be globally
visable (mostly personal preferences for the web interface) but it
means we've no way to discover the userprofile. We're stuck waiting for
this fix, I'm afraid.


More information about the Patchwork mailing list