#24370 closed Cleanup/optimization (fixed)
Recommend that all new projects use a custom user model
Reported by: | Carl Meyer | Owned by: | Krzysztof Gogolewski |
---|---|---|---|
Component: | Documentation | Version: | 1.7 |
Severity: | Normal | Keywords: | |
Cc: | cmawebsite@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Right now, our custom user model docs are buried deep in the auth-customization docs, and are a bit intimidating - because it assumes that you would only need a custom user model if making significant departures from the default User, the examples used require a fair amount of boilerplate, and there are several big scary warning callouts. I've dealt with many people in #django in a position where they needed a custom user model, but had already launched the project without one, leaving them with no good options. Several of these people specifically said that they'd considered using a custom user model initially, but were scared off by the docs.
Every single new Django project, even if it doesn't initially need anything different from the default user model, should start with a two-line custom user model like this:
from django.contrib.auth.models import AbstractUser class User(AbstractUser): pass
It's trivial to setup, there is no downside, and there is massive upside: later in the project, when you realize that you need unique emails, or an additional field, or some other departure from the default, it's easy to use migrations to modify an existing custom user model. It's extremely difficult to migrate from the default user model to a custom user model.
(Ironically, the warnings in the documentation that scare people away from starting with a custom user model are all about problems with switching to one mid-stream; problems that would be totally avoided if people did start off with a custom user model!)
My proposal: we reorganize the "Customizing Authentication" page to recommend and feature the super-simple custom user model as shown above. We also link to that page from the tutorial with a recommendation to start your real project with a custom user model. (I don't know that we should actually modify the tutorial code, as that's a bit of additional complexity, but I think people should at least be encouraged to go look at the auth-customization docs.)
Change History (11)
comment:1 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 10 years ago
See also #20629 - "Admonitions in custom User model documentation may be scaring off users".
comment:3 by , 10 years ago
Would modifying the default project template be going a step too far? Otherwise, I think most people probably wouldn't come across this until it's too late unless they are experienced developers.
comment:4 by , 10 years ago
The more I think about changing the default project template, the more I like the idea. If this is the way you should start a project, why wouldn't we do it in the default template?
The main downside would just be that it's another concept to understand, a few more files and lines of code in the default template. And we'd have to settle the bikeshed of where to put the skeleton custom user model - it needs to go in an app, and having the startproject template include a pre-created app in INSTALLED_APPS feels like a significant change.
comment:5 by , 10 years ago
Cc: | added |
---|
Maybe we could make a manage.py startuserapp
which creates an app with a custom user that uses an email address as the username by default.
comment:6 by , 10 years ago
I think adding a second startproject command or template, or adding something built-in which uses email address is username, is definitely going too far for this ticket.
comment:7 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I'd like to help out by making the documentation change to reflect whatever is decided. I'm assigning myself this ticket -- feel to steal it back.
I agree @timgraham that modifying the default project template appears to be way beyond the scope of this ticket. I think a good first step would be massage the wording around this.
I'm relatively new Django developer (just a couple years) and the wording around this is very scary. I originally was dissuaded from using a custom user model, luckily we migrated to one before the application went to production. However, the transition was still painful as all of our migrations changed, etc.
If a consensus can be made, I'm happy to update the documentation. Please advise next steps...
comment:9 by , 8 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
+1
Having gone through the pain of doing that change a few times, I can confirm there is no good solution once you've started without a custom user model.