Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#7932 closed (fixed)

Make it easier to use a subclass of auth.User in the admin site.

Reported by: ElliottM Owned by: brosner
Component: contrib.admin Version: master
Severity: Keywords: subclass user admin model inheritance
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: UI/UX:

Description

I want to be able to create a subclass of the auth.User model, and entirely theplace it's use with my subclass throughout my site, including the Admin site. For the most part, this works.

There are two places it doesn't, however, and this ticket aims to fix those two places. The first is easily fixable.

In the UserAdmin's overridden "add_view" method, where it creates a new User. On lines 34 and 45, the UserCreationForm is hard-coded in as the form for the page. UserCreationForm is a Modelform with the model set to User. This means that if you create a subclass of User, and use a subclass of UserAdmin to manage it, your creation form will still create Users, rather than SubclassedUsers. On lines 58 and 60, the same function hard-codes references to the User model for help_text purposes and such in the context sent to the template.

The fix is to set a "creation_form" attribute in the UserAdmin declaration, and set the UserCreationform there, and change the references to UserCreationForm over to self.creation_form. Subclasses of UserAdmin are free to set the creation_form value to their own form rather than having to override the entire add_view function (as well as import everything it requires). Since "self.model" is already a value inherited from ModelAdmin, just use that instead of the reference to "User" in the context set-up. The patch I included does both of these.

The other problem is harder to fix, and I don't have a patch for it. Once on the change form for a particular SubclassedUser, the link to the "change password form" provided the the password field's help_text simply does not work. When you click on it, nothing happens. I'm, pretty sure this is because of the way admin.site.root handles URLS:

154 	            match = USER_CHANGE_PASSWORD_URL_RE.match(url)
155 	            if match:
156 	                return self.user_change_password(request, match.group(1))

Up above, USER_CHANGE_PASSWORD_URL_RE is defined as a regex that hard-codes in "user" to the url. This means that the password change URL of the SubclassedUser never matches this regex and the view never gets called.

Fixing both of these will go a very long way towards making a seamless subclass of User possible.

Attachments (1)

user_model_admin_subclass.diff (2.1 KB) - added by ElliottM 7 years ago.

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by ElliottM

comment:1 Changed 7 years ago by ElliottM

  • Needs documentation set
  • Needs tests set
  • Patch needs improvement set

One more note: I wasn't able to recreate the circular import mentioned in one of the removed lines in the diff, but that's not to say it has gone away. Setting patch needs improvement because of the URL thing as well as the circular import thing.

comment:2 Changed 7 years ago by ericholscher

  • milestone set to post-1.0
  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 7 years ago by brosner

  • milestone changed from post-1.0 to 1.0 beta
  • Owner changed from nobody to brosner
  • Status changed from new to assigned
  • Triage Stage changed from Design decision needed to Accepted

comment:4 Changed 7 years ago by brosner

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [8280]) Fixed #7932 -- Made it easier to use a custom User model with the admin. Added add_form attribute to UserAdmin and removed hard-coded dependancies to User. Thanks ElliottM for the patch.

comment:5 Changed 7 years ago by brosner

Elliott can you make a new ticket for the second problem you described? Thanks.

comment:6 Changed 7 years ago by smcoll

For anyone tracking this ticket, the "new ticket for the second problem" is 8202, and has also been resolved.

comment:7 Changed 4 years ago by jacob

  • milestone 1.0 beta deleted

Milestone 1.0 beta deleted

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