Skip to content

Update perms_map in DjangoModelPermissions and DjangoObjectPermissions #7719

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

RashA07
Copy link

@RashA07 RashA07 commented Feb 17, 2021

Description

Django permissions allows for 'view_modelname'. When users have view_modelname permission, these permission classes don't recognize it and reject access to the user.

My specific case was assigning customers to a group with the group having specific permissions allowed from the model permissions. Made this edit in an extension of DjangoModelPermissions to make it work. Thought it would be useful to have inherently. Not sure if this solves an existing error of any sort.

Django permissions allows for 'view_modelname'. When users have view_modelname permission, these permission classes don't recognize it and reject access to the user.

My specific case was assigning customers to a group with the group having specific permissions allowed from the model permissions. Made this edit in an extension of DjangoModelPermissions to make it work. Thought it would be useful to have inherently.
@danlamanna
Copy link

+1 - it's actually really surprising that the defaults don't require view permissions for at least GET.

@stale
Copy link

stale bot commented Apr 28, 2022

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.

@stale stale bot added the stale label Apr 28, 2022
Copy link
Member

@auvipy auvipy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to refer this to more experienced maintainers of the framework

@stale stale bot removed the stale label Dec 8, 2022
@auvipy auvipy requested review from kevin-brown and rpkilby December 8, 2022 04:10
Copy link

stale bot commented Apr 28, 2025

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.

@stale stale bot added the stale label Apr 28, 2025
@auvipy auvipy requested a review from a team April 28, 2025 03:23
@stale stale bot removed the stale label Apr 28, 2025
Copy link
Collaborator

@peterthomassen peterthomassen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@danlamanna says:

the defaults don't require view permissions for at least GET

The current code (without this PR) does look like a permission is not required by default when using Django-style permissions, so even users without the permission can GET the resource.

The contributor of this PR, @RashA07, says:

When users have view_modelname permission, these permission classes don't recognize it and reject access to the user.

This seems to be saying the opposite (nobody can access the resource, even with the permission).

  1. Did I get that right?
  2. If so, can you provide a reproducible example?

One form for a reproducible example would be a test (which would be required for merge anyway).

Once understood and confirmed, I think we can fix this in a major release.

Copy link

stale bot commented Jul 19, 2025

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.

@stale stale bot added the stale label Jul 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants