UserAdmin views should use attribute or current model to lookup the template paths

[james Turnbull]

When overriding the add_view() and user_change_password() in UserAdmin I expected it to use the current model names to find the templates (like the rest of admin).

However, it was hardcoded to use admin/auth/user/add_form.html and admin/auth/user/change_password.html.

Attached patch adds in the path for the current model, falling back to the above for backwards compatibility.

[james Turnbull]

Any chance this could get set for 1.1 rather than 1.2?

I only ask as it goes very well with my other (set for 1.1) patch here: #10694

[Alex Gaynor]

That's a bug, this is, in my view, a feature, admittingly a totally low overhead, noncontroversial no work one, but where that bar lies is for a committer to decide, so I've been intentionally rather conservative here.

[james Turnbull]

Cool, thanks for taking the time to explain.

[james Turnbull]

More flexible version

[james Turnbull]

After thinking about this further, I've submitted a new patch and knocked this bug back to "Unreviewed". Apologies for messing it around.

Taking cues from ModelAdmin, this version first looks for local attributes add_form_template and change_password_template before then attempting the template based off the models name, and finally falling back to the auth.user template (for backwards compatiblity).

Also to follow the convention of ModelAdmin in this version I define a variable for the context and pass that into render_to_response rather than defining a variable for the templates as I did in the previous patch.

[james Turnbull]

Fixed a typo in the Summary.

[James Bennett]

1.2 is feature-frozen, moving this feature request off the milestone.

[james Turnbull]

This patch is ready to go and accepted - can someone push this into Django 1.3?

[james Turnbull]

This was mostly fixed in #12218, so closing as a dupe.

[james Turnbull]

Apologies, I meant: [12218]

[Jacob]

Milestone 1.3 deleted