Fixed #15299 -- Started the process of migrating the auth context processor support classes into the auth context processor module. Thanks to shailesh for the report, and v1v3kn for the draft patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15635 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2011-02-23 13:36:58 +00:00
parent 6ce03dd888
commit 7aa84917a4
6 changed files with 85 additions and 29 deletions

View File

@ -1,7 +1,34 @@
from django.core.context_processors import PermWrapper
from django.utils.functional import lazy, memoize, SimpleLazyObject
from django.contrib import messages
# PermWrapper and PermLookupDict proxy the permissions system into objects that
# the template system can understand.
class PermLookupDict(object):
def __init__(self, user, module_name):
self.user, self.module_name = user, module_name
def __repr__(self):
return str(self.user.get_all_permissions())
def __getitem__(self, perm_name):
return self.user.has_perm("%s.%s" % (self.module_name, perm_name))
def __nonzero__(self):
return self.user.has_module_perms(self.module_name)
class PermWrapper(object):
def __init__(self, user):
self.user = user
def __getitem__(self, module_name):
return PermLookupDict(self.user, module_name)
def __iter__(self):
# I am large, I contain multitudes.
raise TypeError("PermWrapper is not iterable.")
def auth(request):
"""
Returns context variables required by apps that use Django's authentication

View File

@ -84,28 +84,30 @@ def request(request):
return {'request': request}
# PermWrapper and PermLookupDict proxy the permissions system into objects that
# the template system can understand.
# the template system can understand. They once lived here -- they have
# been moved to django.contrib.auth.context_processors.
class PermLookupDict(object):
def __init__(self, user, module_name):
self.user, self.module_name = user, module_name
from django.contrib.auth.context_processors import PermLookupDict as RealPermLookupDict
from django.contrib.auth.context_processors import PermWrapper as RealPermWrapper
def __repr__(self):
return str(self.user.get_all_permissions())
class PermLookupDict(RealPermLookupDict):
def __init__(self, *args, **kwargs):
import warnings
warnings.warn(
"`django.core.context_processors.PermLookupDict` is " \
"deprecated; use `django.contrib.auth.context_processors.PermLookupDict` " \
"instead.",
PendingDeprecationWarning
)
super(PermLookupDict, self).__init__(*args, **kwargs)
def __getitem__(self, perm_name):
return self.user.has_perm("%s.%s" % (self.module_name, perm_name))
def __nonzero__(self):
return self.user.has_module_perms(self.module_name)
class PermWrapper(object):
def __init__(self, user):
self.user = user
def __getitem__(self, module_name):
return PermLookupDict(self.user, module_name)
def __iter__(self):
# I am large, I contain multitudes.
raise TypeError("PermWrapper is not iterable.")
class PermWrapper(RealPermWrapper):
def __init__(self, *args, **kwargs):
import warnings
warnings.warn(
"`django.core.context_processors.PermWrapper` is " \
"deprecated; use `django.contrib.auth.context_processors.PermWrapper` " \
"instead.",
PendingDeprecationWarning
)
super(PermWrapper, self).__init__(*args, **kwargs)

View File

@ -158,6 +158,12 @@ their deprecation, as per the :ref:`Django deprecation policy
* :class:`~django.http.CompatCookie` will be removed in favour of
:class:`~django.http.SimpleCookie`.
* :class:`django.core.context_processors.PermWrapper` and
:class:`django.core.context_processors.PermLookupDict`
will be moved to :class:`django.contrib.auth.context_processors.PermWrapper`
and :class:`django.contrib.auth.context_processors.PermLookupDict`,
respectively.
* 2.0
* ``django.views.defaults.shortcut()``. This function has been moved
to ``django.contrib.contenttypes.views.shortcut()`` as part of the

View File

@ -423,7 +423,7 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
via the :doc:`messages framework </ref/contrib/messages>`.
* ``perms`` -- An instance of
``django.core.context_processors.PermWrapper``, representing the
``django.contrib.auth.context_processors.PermWrapper``, representing the
permissions that the currently logged-in user has.
.. versionchanged:: 1.2
@ -435,6 +435,11 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
``user.get_and_delete_messages()``. It has been changed to include any
messages added via the :doc:`messages framework </ref/contrib/messages>`.
.. versionchanged:: 1.3
Prior to version 1.3, ``PermWrapper`` was located in
``django.contrib.auth.context_processors``.
django.core.context_processors.debug
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -828,3 +828,15 @@ Rationale for this decision:
* This location wasn't included in the translation building process for
JavaScript literals.
``PermWrapper`` moved to ``django.contrib.auth.context_processors``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In Django 1.2, we began the process of changing the location of the
``auth`` context processor from ``django.core.context_processors`` to
``django.contrib.auth.context_processors``. However, the
``PermWrapper`` support class was mistakenly omitted from that
migration. In Django 1.3, the ``PermWrapper`` class has also been
moved to ``django.contrib.auth.context_processors``, along with the
``PermLookupDict`` support class. The new classes are functionally
identical to their old versions; only the module location has changed.

View File

@ -1334,9 +1334,13 @@ Permissions
The currently logged-in user's permissions are stored in the template variable
``{{ perms }}``. This is an instance of
:class:`django.core.context_processors.PermWrapper`, which is a
:class:`django.contrib.auth.context_processors.PermWrapper`, which is a
template-friendly proxy of permissions.
.. versionchanged:: 1.3
Prior to version 1.3, ``PermWrapper`` was located in
``django.contrib.auth.context_processors``.
In the ``{{ perms }}`` object, single-attribute lookup is a proxy to
:meth:`User.has_module_perms <django.contrib.auth.models.User.has_module_perms>`.
This example would display ``True`` if the logged-in user had any permissions