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 <step...@that.guru> > > Closes: #313 > > Reported-by: Bjorn Helgaas <helg...@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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork