Two design options:

1. Break backwards compatibility by updating theDjangoModelPermissionsGET check to require the new permission. This has the advantage of being more secure by default, but the major disadvantage of breaking backwards compatibility.
2. Create a new subclass with the stricter permissions check. Advantage is it maintains compatibility, disadvantage is more auth classes to document/test/maintain.

As a user that expected the default behaviour to be to not grant read access to all users, I prefer 1, but I'm not sure how painful you consider a back-incompatible change to be.

I'd suggest (1) but only merging it with the next major version change.

Sounds good. I've updated the code with this approach. The tests are currently failing because this permission doesn't exist on older versions by default; wonder what the approach should be for testing this? Is there precedent elsewhere that I could compare/copy?

Might be able to do something like adding the view permission only in the new has_view_permission test, and skipping these tests if version < nextversion?

We plan on dropping Django 1.11 in April when the 2.2 LTS release is cut. This also coincides with the EOL for Django 2.0, meaning that the version differences won't matter since 2.1 will be the minimum supported version.

Basically, this PR will need to hang around until we're ready to prepare the next major DRF release.

Ah gotcha, that makes sense. Will hang tight on this changeset then.

This is a welcome change.

Moving this to 3.11, since we're not dropping Django 1.11 support until at least December.

I am using this change in my project(by overriding DjangoObjectPermissions and setting the .perms_map property).
It is working as intended when listing objects using ModelViewSet. However when trying to retrieve a single item from the same view I am getting "detail": "Not found." error. This doesn't happen when the user making the request is a superuser. Adding all permission to the non-superuser testing user hasn't solved this as well.
@paultiplady have you tested this case?
I have spent a few hours on it and can't find anything wrong with my environment.

Hello, any update on the status of this feature?

Hoping to see progress on this MR... I am already using it in my code but still would be nice to see it goes into the DRF codebase.

Hey there, can anyone give an update on what is missing from this PR so that some of us who are using DRF in@openwisp may help out in case it's doable for us? We will implement our own solution for this anyway so maybe it's worth to help here instead.

@nemesisdesign Have added a comment above on a small tweak that'd be needed. Happy to take that either on this PR, on against a new one.

@nemesisdesign Have added a comment above on a small tweak that'd be needed. Happy to take that either on this PR, on against a new one.

Cool, what about the OPTIONS method?

It is indeed a very useful addition.... hope it gets merged into the next release. We have been using this implementation for a long while, but it feels awkward each time when I have to explain why DRF doesn't include this solution..

I am using this change in my project(by overriding DjangoObjectPermissions and setting the .perms_map property).
It is working as intended when listing objects using ModelViewSet. However when trying to retrieve a single item from the same view I am getting "detail": "Not found." error. This doesn't happen when the user making the request is a superuser. Adding all permission to the non-superuser testing user hasn't solved this as well.
@paultiplady have you tested this case?
I have spent a few hours on it and can't find anything wrong with my environment.

Hi, @BlackXnt Yes there's an issue with this PR, I have opened#8009 to deal with this case, you can do a similar thing and see if it resolves your problem. 👍

#8009 is based on work we're doing in OpenWISP:openwisp/openwisp-users#251. Would be great to see this handled directly in DRF. Let us know if it needs improvement. We'll put effort in helping out on this (me,@ManishShah120 and@atb00ker).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.