Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#18136 closed Cleanup/optimization (fixed)

Documentation for PermWrapper is wrong

Reported by: Adrien Lemaire Owned by: nobody
Component: Documentation Version: 1.4
Severity: Normal Keywords:
Cc: lemaire.adrien@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: yes UI/UX: no

Description

Doc says at /en/dev/topics/auth/:

The currently logged-in user's permissions are stored in the template variable {{ perms }}. This is an instance of django.contrib.auth.context_processors.PermWrapper, which is a template-friendly proxy of permissions.

Changed in Django 1.3: Prior to version 1.3, PermWrapper was located in django.contrib.auth.context_processors.

That is wrong, PermWrapper was located in django.core.context_processors.

Attachments (1)

0001-Fix-PermWrapper-doc.patch (825 bytes ) - added by Adrien Lemaire 13 years ago.

Download all attachments as: .zip

Change History (7)

by Adrien Lemaire, 13 years ago

comment:1 by Adrien Lemaire, 13 years ago

Cc: lemaire.adrien@… added
Type: UncategorizedCleanup/optimization

comment:2 by Adrien Lemaire, 13 years ago

Might also be a good idea to edit the documentation to let the user know that he doesn't need to add django.contrib.auth.context_processors.PermWrapper in his TEMPLATE_CONTEXT_PROCESSORS, because django.contrib.auth.context_processors.auth already includes it.

comment:3 by Claude Paroz, 13 years ago

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

Patch marked as needs improvement due to your comment:2.

comment:4 by Adrien Lemaire, 13 years ago

hmm I don't really know how to improve the doc. In fact, this information is already included in the doc:

.. admonition:: Technicality

   Technically, these variables are only made available in the template context
   if you use :class:`~django.template.context.RequestContext` *and* your
   :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting contains
   ``"django.contrib.auth.context_processors.auth"``, which is default. For
   more, see the :ref:`RequestContext docs <subclassing-context-requestcontext>`.

I was looking for permissions and started to read from the subtitle without seeing the admonition.
Therefore, the doc is correct. My concern was that without reading that admonition, I needed a few time to figure that out:

Because I started with a bad {{ perms.app_label.can_edit_model }} (when it should be {{ perms.app_label.change_model }} , after reading the PermWrapper code, I though I'd need to call {{ request.perms.app_label.can_edit_model }} , to add the context_processor etc.

What would be nice is to raise a PermissionDoesNotExist or something like that if trying to call {{ perms.app_label.can_edit_model }} when DEBUG=True. If you agree with that, I'll create a new ticket because it's unrelated to the documentation.

Version 1, edited 13 years ago by Adrien Lemaire (previous) (next) (diff)

comment:5 by Claude Paroz, 13 years ago

Resolution: fixed
Status: newclosed

In [17913]:

Fixed #18136 -- Fixed pre-1.3 PermWrapper? location in docs. Thanks Adrien Lemaire for the patch.

(Fixed by dyslectic claudep, s/18316/18136/)

Last edited 13 years ago by Claude Paroz (previous) (diff)

in reply to:  4 comment:6 by Claude Paroz, 13 years ago

Replying to Fandekasp:

What would be nice is to raise a PermissionDoesNotExist or something like that if trying to call {{ perms.app_label.can_edit_model }} when DEBUG=True. If you agree with that, I'll create a new ticket because it's unrelated to the documentation.

Yes, this would be another ticket, and the setting would be probably TEMPLATE_DEBUG.

Note: See TracTickets for help on using tickets.
Back to Top