Warn of clash between generic view context variables and template context processor variables

[Mathieu Hinderyckx]

Problem

I have a custom User model, and a DetailView of that Model.

urls.py:

urlpatterns = [
    url(r'^(?P<pk>\d+)/$', views.UserDetailView.as_view(), name='user-detail'),
]

views.py:

class UserDetailView(DetailView):
    model = User
    template_name = 'app_example/profile.html'

Template:

<h2>Log in information</h2>
{% if user.is_authenticated %}
    <p>User authenticated. User oject: {{user}}.</p>
{% else %}
    <p>User not authenticated. User object: {{user}}.</p>
{% endif %}
 <h2>DetailView Object</h2>
<p>{{object}}</p>

To replicate the problem; Create 2 users, log in with 1 user, and visit the detailpage with the pk of the 2nd user. Do this also when both users are logged out.

Now, what happens is that the user.is_authenticated block is (wrongfully) always shown, and {{user}} is always the Detailview object instead of the request.user. The {{object}} is the Detailview object (as expected).

Problem

The documentation and example on DetailView mentions that its item is available through {{object}}. However, it's also available by default as {{obj._meta.model_name}} through the get_object_context_name() method from the SingleObjectMixin, which is not clearly mentioned. When using the 'User' model, this interferes with the {{user}} context variable from middleware. In any case (user = request.user or user = object), the 'is_authenticad' field on that variable should evaluate to False in the example above, but does not, why that is, is not clear to me yet. As this {{user}} variable is commonly used with authentication on sites, I think this should be mentioned clearly. Now, for example menu's for logged-in users only are shown while this shouldn't be. If this variable is the object from the DetailView instead of the request, this might lead to a lot of unexpected behaviour when developing templates.

Workaround

set 'context_object_name' on the DetailView to something else.

[Maxime Lorant]

Your solution seems to break forward compatibility, since the public method get_context_object_name describes the default behavior in the current documentation: ​https://docs.djangoproject.com/en/1.8/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.get_context_object_name, plus I think it is a good implementation, besides this case...

Maybe we could either :

• exclude some reserved variable names (especially user and site). Problem: not really pretty and would be reserved to variables included by Django ;
• change the behaviour if the variable is already used by one of the installed middleware. Problem: if you remove a middleware, it might break the generic view template (since the variable could be renamed as a side effect).

Both solutions have limits, especially the second one...

[Tim Graham]

I think trying to be "smart" and change or disallow the certain context variable names won't be worth it. I'd rather work to deprecate the auth context_processor (user can be replaced by request.user, but a solution for replacing perms isn't so clear). Meanwhile, we can certainly improve the documentation.

[Jacek Bzdak]

I'll do it

[Tim Graham]

​PR

[Tim Graham <timograham@…>]

In 494b7986:

Fixed #25397 -- Documented class-based view context variable clash with context processors.

[Tim Graham <timograham@…>]

In d83454fb:

[1.8.x] Fixed #25397 -- Documented class-based view context variable clash with context processors.

Backport of 494b7986a3e5996d857b085f188a630d1504d9ca from master

[Tim Graham <timograham@…>]

In 488538e:

[1.9.x] Fixed #25397 -- Documented class-based view context variable clash with context processors.

Backport of 494b7986a3e5996d857b085f188a630d1504d9ca from master