Patch delegation using the REST API broken on old instances #313
Labels
Comments
stephenfin
added a commit
that referenced
this issue
Sep 24, 2019
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> (cherry picked from commit ab35df8)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some users have reported that delegation via the REST API, specifically using git-pw, is broken. Specifically, they see this issue:
However, a quick look at the project overview page for said project shows that this is not the case. Seems like an obvious bug.
The text was updated successfully, but these errors were encountered: