[Django] #30040: Documentation on permissions on templates is wrong
Django
-------------------------------------+-------------------------------------
Reporter: Sakerdot | Owner: nobody
Type: Bug | Status: new
Component: | Version: 2.1
Documentation | Keywords: template
Severity: Normal | permissions documentation
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Following
https://docs.djangoproject.com/el/1.11/topics/auth/default/#permissions,
it's suggested that permissions should be checked on templates like this:
{% if perms.foo.can_vote %}
However, while running an application on production (DEBUG = False on
settings.py), it seems like the proper way to do this is {% if
perms.foo.vote %}, without the can_ prefix, because the perms dictionary
doesn't have any item with can_ and it fails otherwise.
I think I tested this on a local environment and it worked fine with the
can_ prefix, so not sure what the deal is here.
--
Ticket URL: <https://code.djangoproject.com/ticket/30040>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage:
permissions documentation | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Claude Paroz):
I think `can_vote` here is to be considered as any custom permission
codename added to some model, it does not refer to a default permission
name automatically created for models. The default names are `add_foo`,
`change_foo`, `delete_foo` (and since Django 2.1, `view_foo`).
So the question is: should we use a standard permission codename in the
examples instead of an arbitrary permission codename? I have no strong
opinion on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:1>
Django
-------------------------------------+-------------------------------------
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
permissions documentation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
Now I see that a confusion may happen because the standard permission
verbose name is "Can view foo". So I would suggest to either use a
standard add/change/delete/view permission codename, or use a custom name
that doesn't have `can` in its name (or anything else which might suggest
it is a standard permission).
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => lqez
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: lqez => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:4>
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: (none) => 2w3
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:5>
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 2w3):
https://github.com/django/django/pull/10757
can_vote is not django standard permission expression.
so, fixed to can_vote to add_vote in permission detail expression.
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:6>
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Claude Paroz):
I think that generally when the Django documentation talks about the
`polls` app, it refers to the tutorial app, with models `Question` and
`Choice`, where `votes` is a field of `Choice`. In that context, using
`add_vote` is at least as much confusing as the `can_vote` perm name. If
we want to stick with default-created permissions, we should probably use
`add_choice`.
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: Adrian Samatan | Owner: 2w3
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Adrian Samatan | Owner: 2w3
Type: | Status: assigned
Cleanup/optimization |
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by James Pic):
I kind of agree with everybody here. But from a higher perspective, it
seems to me that the stake is rather to teach the user how to add a
backend that supports can vote, ie.:
"Now, create a polls/backend.py file with the following:
{{{
class AuthenticationBackend:
def authenticate(self, *args):
"""
Always return ``None`` to prevent authentication within this
backend.
"""
return None
def has_perm(self, user_obj, perm, obj=None):
if not perm.startswith('polls.'):
return False
# only allow authenticated users to vote for example
if not user_obj.is_authenticated:
return False
if 'voters' in user_obj.groups.values_list('name', flat=True)
return True
)
}}}
Then add it to settings:
{{{
AUTHENTICATION_BACKENDS = [
'django.contrib.auth.backends.ModelBackend',
'polls.backends.AuthenticationBackend',
]
}}}
IMHO, teaching how to hack the permission system to their liking is what's
a stake here, rather than the name of the permission. Otherwise, users
might do manual permission checking in the template, instead of going
through the permission abstraction layer, and their permission refactoring
will be a lot harder - only tests can save them.
Sorry my text isn't good/worked out so that you can just reuse it, but I
hope that should give you some ideas.
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:9>
Django
-------------------------------------+-------------------------------------
Type: | Ramezani
Cleanup/optimization | Status: assigned
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Accepted
permissions documentation |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: 2w3 => Hasan Ramezani
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: Adrian Samatan | Owner: Hasan
Type: | Ramezani
Cleanup/optimization | Status: assigned
Component: Documentation | Version: 2.1
Severity: Normal | Resolution:
permissions documentation | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: Adrian Samatan | Owner: Hasan
Type: | Ramezani
Component: Documentation | Version: 2.1
Severity: Normal | Resolution: fixed
Keywords: template | Triage Stage: Ready for
permissions documentation | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"b7795d7673f51daf288ac80616ef69b05918ca6b" b7795d76]:
{{{
#!CommitTicketReference repository=""
revision="b7795d7673f51daf288ac80616ef69b05918ca6b"
Fixed #30040 -- Used default permission name in docs examples to avoid
confusion.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: Adrian Samatan | Owner: Hasan
Type: | Ramezani
Cleanup/optimization | Status: closed
Component: Documentation | Version: 2.1
Severity: Normal | Resolution: fixed
Keywords: template | Triage Stage: Ready for
permissions documentation | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson <carlton.gibson@…>):
In [changeset:"a73489f162003472708887fac9b98987af6464fd" a73489f1]:
{{{
#!CommitTicketReference repository=""
revision="a73489f162003472708887fac9b98987af6464fd"
[3.0.x] Fixed #30040 -- Used default permission name in docs examples to
avoid confusion.
Backport of b7795d7673f51daf288ac80616ef69b05918ca6b from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30040#comment:13>