#32599: django.contrib.auth.forms.py should always refer to User as
get_user_model()
-------------------------------+-----------------------------------------
Reporter: Joe Michelini | Owner: Joe Michelini
Type: Uncategorized | Status: assigned
Component: contrib.auth | Version: 3.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------
Description changed by Joe Michelini:
Old description:
> == Inconsistent Reference
>
> In some sections of django.contrib.auth.forms.py, when referring to the
> User model, Django wisely uses get_user_model(), so whether we decide to
> use the built-in User model, extend it, or use our own, we always get the
> right user when importing these forms.
>
> However, in the UserCreationForm for example, Django instead explicitly
> refers to the built-in user found at django.contrib.auth.models.
>
> This causes some forms to work and some forms to fail when using a custom
> or extended User model, even though extending the built-in User model is
> suggested in the Django documentation.
>
> This is an easy fix and would require all forms in
> django.contrib.auth.forms to refer to get_user_model() as opposed to the
> imported built-in User. In the case where a custom User model is not
> being utilized, get_user_model() will automatically refer to the built-in
> User.
New description:
== Inconsistent Reference
In some sections of `django.contrib.auth.forms.py`, when referring to the
User model, Django wisely uses `get_user_model()`, so whether we decide to
use the built-in User model, extend it, or use our own, we always get the
right user when importing these forms.
However, in the `UserCreationForm` for example, Django instead explicitly
refers to the built-in user found at `django.contrib.auth.models`.
This causes some forms to work and some forms to fail when using a custom
or extended User model, even though extending the built-in User model is
suggested in the Django documentation.
This is an easy fix and would require all forms in
`django.contrib.auth.forms` to refer to `get_user_model()` as opposed to
the imported built-in `User`. In the case where a custom User model is not
being utilized, `get_user_model()` will automatically refer to the built-
in User.
To reproduce:
1. Start a new Django project and initiate an app.
2. In `models.py` of your app, sub-class `AbstractUser` by importing it
from `django.contrib.auth.models`.
3. In settings.py, add `AUTH_USER_MODEL=yourapp.YourSubClassedUser` (this
is all standard).
{{{
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
pass
}}}
4. Register a view and associated url to render a `UserCreationForm`,
perhaps using `CreateView` or `FormView`.
{{{
from django.shortcuts import render
from .models import User
from django.contrib.auth.forms import UserCreationForm
from django.views.generic.edit import FormView, CreateView
class RegisterView(CreateView):
model = User
form_class = UserCreationForm
template_name = 'users/register.html
}}}
5. Render the form in a template, and run migrations for the first time.
6. Attempt to start the server. This will throw the following error:
{{{
AttributeError: Manager isn't available; 'auth.User' has been swapped for
'users.User'
}}}
In the documentation, Django claims that sub-classing the built-in User is
not only recommended, but that it will behave exactly like the built-in
User model. Patching `django.contrib.auth.forms.py` would ensure this.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32599#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.c030fc0dafb6c0b4b76e35c57629ed8e%40djangoproject.com.
