﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
25397	Warn of clash between generic view context variables and template context processor variables	Mathieu Hinderyckx	Jacek Bzdak	"== 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.
"	Cleanup/optimization	closed	Documentation	1.8	Normal	fixed			Accepted	1	0	0	0	1	0
