#10061: incorrect logout link in admin
-------------------------------------------+--------------------------------
Reporter: lashni | Owner: mtredinnick
Status: new | Milestone: 1.1
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 1 |
-------------------------------------------+--------------------------------
Comment (by russellm):
Replying to [comment:68 Alex]:
> Another possible bug: The password_change_done method on AdminSites
reverses using the form reverse('%s:password_change_done' % self.name),
while the render method on RelatedFieldWidgetWrapper uses the form
reverse('admin:%s_%s_add' % info, app_name=self.admin_site.name). My
understanding is that the 2nd form would be correct,
You are correct. I've fixed this in my local branch.
> however it seems that the term app_name is being used inconsistently,
AdminSite instances have both a name and an app_name, here we are passing
the name as a parameter named app_name, which is rather confusing.
As I noted in [http://code.djangoproject.com/ticket/10061#comment:60
comment 60], the app_name argument to Context and reverse should probably
be something like 'current_app'. I'll make this change.
> The get_root_path method will, as far as I can tell, fail using the old
admin.site.root form.
Can you elaborate on the error case here? The only way I can generate
problems is if I mix old-style and new-style admin registrations, which is
understandable given that the old-form doesn't define (or utilize) the
app_name. I don't see any problem with a standard "old-admin registration
plus admin docs" setup, or a 'multiple new-admin plus admin docs".
> Another concern is the use of app_name on Context, I think this
attribute should be exclusively on RequestContext, as this is the object
that knows about the rest of the Django environ. The only change that
needs to be made in light of this is having the URLNode.render use
getattr(context, 'app_name', None) in place of context.app_name.
Hrm.. Not sure I agree here. RequestContext is the context that knows
about the request, not necessarily the entire environment (although, as a
web app, a lot of the current environment is contained or associated with
the request). I don't think there's any examples in admin, but I can see
of situations where a simple help page in a redeployable app might return
a Context, rather than a RequestContext, but it would still be appropriate
to be able to reverse a name to that help page.
> Finally the new form for extending admin urls needs to be documented (as
does the namespacing infrastructure probably).
Granted. I'm waiting until the syntax settles down before I start writing
docs.
I would, however, make some sort of comment about glass houses... the
include(object.urls) notation that you contributed wasn't documented until
last night, and you didn't write the docs :-)
--
Ticket URL: <http://code.djangoproject.com/ticket/10061#comment:70>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
