Django: Getting Started Transcripts
Chapter: Users and Account Management
Lecture: Customizing the user model

Login or purchase this course to watch this video and the rest of the course contents.
0:00 You've already seen the user model that comes with Django. But what if you want to do something that the default model can't?
0:07 Well, you have three choices, if you only want to change the behavior of methods
0:12 but not the underlying data structures you can inherit from user and change your configuration to point to your new object.
0:20 I've never personally done this one. The more likely case is you have additional data you want to associate with the user
0:27 Django calls this a user profile object, You create a user profile object like any other model.
0:35 The only requirement is that it has to be a 1-1 relationship with the user model object. Because the relationship is 1-1,
0:44 Django can set up references from the user to the profile and back again. That way, if you're accessing the logged in
0:51 user from the request object in a view, you're just a d reference away from your extended data. In older versions of Django,
1:00 this was the only real choice. So it's a common approach. But now there's a third option which is to completely replace the user object.
1:10 This requires a new storage class with some configuration to tell Django to use it and a new manager class in that you'll have to implement your
1:19 own create user method amongst some other things. There's a bit more work to get this going.
1:26 But it allows you to do fancy things like change what field is used for login
1:29 If you want your users to log in with an email address instead of a user name. This is the approach you need to take.
1:38 If you've got an existing user base switching from one of the first two modes to the third can be problematic.
1:42 It is possible, but you've got to be very careful. Adding a profile late in the game is no big deal changing how your users log in is going to
1:51 be a problem for the code and for your users. It is best to make this decision up front and stick with it if possible.
2:00 Let's look a little further at that second option, creating a user profile object. The only tricky part here is when the object gets created.
2:09 As the profile object has a 1-1 relationship with the user model, the user model object has to be created first. To make this more complicated,
2:18 you have to consider that different ways the user model object can be created. You might have a self sign up page.
2:25 There is also the Django admin or you might be doing batch imports, each of these is subtly different. You have to make sure that however,
2:34 the user model gets created, the profile object gets created at the same time.
2:39 Enter Djangos signaling system, you can register a function to be called when certain events happen in the system.
2:47 One of the events you can register for is the creation of an object. Like the user model. There's a big exception case here.
2:55 This only works if you're using Django's code, certain bulk database activities are done in the sequel layer and won't trigger these kinds of signals.
3:04 If you stick to the Django admin and use the user models, create user method, you'll be fine. In addition to adding event handling code.
3:14 You also want to make sure your fields are available in the Django admin. There is a way to create sub areas in an admin page that you can take
3:22 advantage of and embed your profiles fields in the user model edits page. Let's go write a user profile.

Talk Python's Mastodon Michael Kennedy's Mastodon