Add a helper function to return the permission string representation to be used with `user.has_perm()`

[Mariatta]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Originally opened in https://code.djangoproject.com/ticket/37021, and was told to create it here.

When checking user's permission using user.has_perm(), I need to pass a string in the format of {Permission.content_type.app_label}.{Permission.codename}

However, the Permission object itself does not provide an easy way to return this string.
The __str__ method of the Permission class returns a string of content_type | name.

I think it would be great if the Permission class can provide the string representation that will allow us to check the permission without having to manually construct it ourselves.

My desired outcome is to be able to do the following.

user_permissions = Permission.objects.filter(...) 
for perm in user_permissions:
    if user.has_perm(perm.perm_string()):
        # let them do stuff

Currently I am doing it as follows:

if user.has_perm(f"{perm.content_type.app_label}.{perm.codename}"):
        # let them do stuff

Proposal:

To add a function within Permission class:

def perm_string(self): # feel free to suggest other name
    return f"{self.content_type.app_label}.{self.codename}"

If you agree, I would like to try to create the PR for this.

See also related ticket https://code.djangoproject.com/ticket/26547
In the related ticket, the proposal was to modify the user.has_perm() function and adding new parameters.
I think adding the helper function to the Permission object is cleaner.

Problem

I need a consistent way to check for user permission (user.has_perm()) for a given Permission object.

Currently I am doing it as follows:

if user.has_perm(f"{perm.content_type.app_label}.{perm.codename}"):
        # let them do stuff

It would be great if the Permission class provides the string representation needed for the user permission check, so that I don't have to construct it myself.

Request or proposal

proposal

Additional Details

No response

Implementation Suggestions

To add a function within Permission class:

def perm_string(self): # feel free to suggest other name
    return f"{self.content_type.app_label}.{self.codename}"

[github-actions]

Thank you Mariatta for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[Mariatta]

I don't understand the difference between request or proposal. But if this feature is accepted, I would like to contribute and create the PR.

[LilyFirefly]

I think doing something here makes sense.

In 37021 Jacob says:

However, although it's just a one-liner, forcing the user to write it themselves will probably alert them to the need to JOIN the content types, or otherwise do an annotation, to avoid an N+1 query problem.

I'll note that this can be mitigated from Django 6.1 with fetch modes.

---

Another idea I had when reading this would be to change has_perm to accept a Permission instance in place of a permission string. That would allow your example to become:

user_permissions = Permission.objects.filter(...) 
for perm in user_permissions:
    if user.has_perm(perm):
        # let them do stuff

Unfortunately, looking at the Django source code for authentication backends, this would require a deeper refactor. It might still be worth doing.

[tim-schilling]

@LilyFirefly Agreed. I was also wondering why has_perm can't accept both formats of the stringified perm too.

@Mariatta proposal would mean you're proposing to add the feature. Request is that you're requesting Django to add the feature. Given you want to do the work, it'd be a proposal.

[Mariatta]

Passing the Permission to the has_perm is also good idea! I also thought it would be better to pass the object itself instead of the string. But as you pointed out, it will require bigger effort, so I started by proposing something smaller.

[adamchainz]

I'm +1 on adding support for passing a Permission directly.

I don't see why you think this would be such a big refactor @LilyFirefly - couldn't we make BaseBackend.has_perm detect that perm is a Permission and stringify it, before doing the existing is check?

[LilyFirefly]

Oh, good point @adamchainz!

[tim-mccurrach]

+1 in general.

A different approach to adding support for has_perm accepting Permission instances, would be to fetch pk's at the same time we fetch the parts that make the permission string and cache them in parallel. It would be a larger refactor, but not massive, and not breaking - I think. That way we can avoid having to stringify the Permission and eliminate the potential n+1 issues (which are admittedly mitigated, though not entirely, by fetch-modes).

EDIT: Looking through the code again. I'd maybe re-assess my conclusion of "but not massive". The way all the methods work together, having two sets to potentially check to would be quite disruptive. The idea might have legs with further thought - I'm less sure now though.

[tim-schilling]

Is there a reason to not use the new string method in place of all the explicit string interpolations in the codebase?