The docs are pretty specific that the forms are only designed to work with the included User model.
IMO the rationale behind this is if you plan to substitute your own model, it is likely that you'll break the behavior of the included form, or more likely, it will produce unintended behavior. For instance, if you wanted to expand the number of characters allowed for a user name from the default of 30 to 100, the included form will still limit the username field to 30 characters or it will fail validation, even if your custom user model allows it. I believe it is expected that if you have a custom user model, you are also planning to override all of the related functionality to match, including the forms related to creating a user, since you have different requirements than what Django provides by default. Otherwise there is no reason to override the User model. If you are fine with the default parameters enforced by the Django User model, but want to add additional information to the user (such as info you would find on a user profile page like address, phone number, etc.), then you should consider creating a separate model with a foreign key back to User so that it can be retrieved when the profile information is needed. See the second paragraph here: https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#extending-the-existing-user-model I would only override the existing User model for the following reasons: 1. You have specific requirements about the information a user can use to authenticate themselves, such as a longer user name, or only accepting an email address as a user name, two-factor authentication, etc. 2. If the current included model is fine, but there is ANY chance that your requirements for logging in will change in the future, create a custom user model now (along with all of the related forms, etc.), even if it exactly mirrors the existing model functionality. You can even inherit directly from User to keep the existing Django batteries intact. While I haven't tried this myself, my understanding is that converting to a custom user model with existing production data can be quite an unpleasant adventure. Having a custom user model in place from the beginning generally means that your existing data stays put in the same table, and changes to your custom user model are handled much more gracefully through standard migrations, rather than potentially invasive and direct schema alterations. If you do use a custom user model, keep the fields to the minimum needed to authenticate and uniquely identify a user, and for information that will be needed on a majority of pages (such as first/surname if you display it on a toolbar or something). If you keep the default context processors, your user model will be loaded on every request, so having a small amount of data to load will be helpful. Other ancillary information can be loaded on demand via a user profile model via the link above. Also, I hope by 'changing the Django codebase' you weren't actually modifying the internal Django code. There shouldn't be any need for that, since pretty much all behavior can be overridden externally. If that is the case, a question about user creation forms will be the least of your concerns given the bugs you'll likely run into. The only reason I would recommend doing so would be for learning the internals in a sandbox or supplying a patch to commit for a bug/improvement, also in a sandbox. HTH, -James On Jan 5, 2015 7:04 PM, "Joel Burton" <[email protected]> wrote: > I'm not sure if this is a bug or intended, hence my asking here before > adding to the bug database. > > In django.contrib.auth.forms, the UserCreationForm and UserChangeForm > refer several times to the User model directly, rather than using > get_user_model(). > > This means that when using a different model for the user model, you can't > use the Django admin unless you create a custom form that overrides this > behavior. > > When I change this in the Django codebase to refer to get_user_model(), it > works just fine -- both with the standard Django User model and with a > custom user model. So, it *appears* that this could work fine as a code fix > for Django. > > It's possible, though, that there's a subtlety I'm missing and that these > should continue to refer to User proper. > > Thoughts, anyone? > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/6e01619f-d9cb-403c-9cd1-0976b2cd5c47%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/6e01619f-d9cb-403c-9cd1-0976b2cd5c47%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXPxmySC8w70EPxtSdJfLhepu%3DLU%3Dq3sFf%3DAPimjk33Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
