On Wed, 2020-06-03 at 18:00 +0200, Ralf Ramsauer wrote:
> Hi,
>
> it seems that the /patches-API is broken under certain conditions. The
> API call throws an exception if the following conditions are met:
> - The user is logged in a browser
> - In the browser, the user requests /api/patches/<someid>/
> - The user is maintainer of the project related to <someid>
>
> This fault can easily be reproduced with a vanilla patchwork instance:
> 1. ./manage.py createsuperuser # create 'admin' superuser
> 2. Login in a browser as admin
> 3. Create some new project
> 4. ./manage.py parsearchive list.mbox # import some patches
> 6. In the browser, navigate to /admin/auth/user/1/change
> and add the user as maintainer of the project
> 7. In the browser, navigate to /api/patches/1
> 8. Exception is thrown
>
> The exception is not thrown, if step 6 is either skipped or reverted.
> Please find the backtrace attached.
Thanks for bringing this up. I spent some time looking at this today.
The reason this is specific to being a project maintainer is that the
editable fields in the browseable API only appear for project
maintainers or superusers. It appears the 'patch.relation' field is
breaking this because we're modifying the output from this:
'relations': {
'patches': [
... list of patches ...
]
},
to this:
'relations': [
... list of patches ...
],
I guess the main issue is that we're going from an object (the relation
through model) thing to a list of objects.
I haven't yet figured out how to preserve the list of input fields
while retaining this style of output. We might need to drop the former
if I can't figure that out.
Stephen
> Thanks
> Ralf
> _______________________________________________
> Patchwork mailing list
> Patchwork@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
