Changes between Initial Version and Version 1 of Ticket #32599


Ignore:
Timestamp:
Mar 27, 2021, 7:30:46 AM (4 years ago)
Author:
Joe Michelini
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #32599 – Description

    initial v1  
    22== Inconsistent Reference
    33
    4 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.
     4In 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.
    55
    6 However, in the UserCreationForm for example, Django instead explicitly refers to the built-in user found at django.contrib.auth.models.
     6However, in the `UserCreationForm` for example, Django instead explicitly refers to the built-in user found at `django.contrib.auth.models`.
    77
    88This 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.
    99
    10 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.
     10This 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.
     11
     12To reproduce:
     13
     141. Start a new Django project and initiate an app.
     152. In `models.py` of your app, sub-class `AbstractUser` by importing it from `django.contrib.auth.models`.
     163. In settings.py, add `AUTH_USER_MODEL=yourapp.YourSubClassedUser` (this is all standard).
     17
     18{{{
     19from django.contrib.auth.models import AbstractUser
     20
     21class User(AbstractUser):
     22    pass
     23}}}
     24
     254. Register a view and associated url to render a `UserCreationForm`, perhaps using `CreateView` or `FormView`.
     26
     27{{{
     28from django.shortcuts import render
     29from .models import User
     30from django.contrib.auth.forms import UserCreationForm
     31from django.views.generic.edit import FormView, CreateView
     32
     33class RegisterView(CreateView):
     34    model = User
     35    form_class = UserCreationForm
     36    template_name = 'users/register.html
     37}}}
     38
     395. Render the form in a template, and run migrations for the first time.
     406. Attempt to start the server. This will throw the following error:
     41
     42{{{
     43AttributeError: Manager isn't available; 'auth.User' has been swapped for 'users.User'
     44}}}
     45
     46In 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.
Back to Top