Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#15115 closed (invalid)

AdminSite and templates hard-code the "admin" namespace in places

Reported by: Christian Hammond Owned by: nobody
Component: Uncategorized Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


It's documented that a custom AdminSite can specify a custom name, which will be used in the namespace for the URLs. Parts of the admin code factor this in, but other don't.

I have a a patch to cover two cases where it's hard-coded, but I don't have an immediate solution for the templates. The templates do such things as:

{% url 'admin:jsi18n' as jsi18nurl %}

What's really needed is something to prefix the variable. I'd be happy to work on a fix, but would need some idea as to what direction you guys would prefer. A custom template tag that factors it in? Some sort of new parameter to url that allows the namespace to be set via a variable? The URL pre-computed and passed in to all admin site contexts?

Attachments (1)

admin_site_url_namespaces_20110119.diff (1.4 KB) - added by Christian Hammond 7 years ago.
Fixes two cases of "admin:" being hard-coded.

Download all attachments as: .zip

Change History (3)

Changed 7 years ago by Christian Hammond

Fixes two cases of "admin:" being hard-coded.

comment:1 Changed 7 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed

This shouldn't be an issue.

As is explained here, namespaces come in two flavors -- application namespaces and instance namespaces. Rules for resolving namespaces are described here, but they don't require you to pass in the current site as the namespace -- you can use the application namespace, and the 'current_app' will be used to differentiate between instances.

comment:2 Changed 7 years ago by Russell Keith-Magee

Sorry - a little clarification:

It's entirely possible that there are cases where the namespace resolution isn't working correctly. However, this ticket doesn't describe such a case (or, at least, not in sufficient detail to reproduce), so I'm closing it on the basis that there's no prima facie need to do what you're describing.

If you can provide an specific case where lookup is failing, please reopen with details.

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