James – Thanks for the reply.
I'd agree that the docs suggest you have things to do if you replace the User with a custom user mode—but the docs also say to use get_user_model() versus hardcoding User ;) It's true that the built-in user form makes assumptions about the length of the username and that the only immediately-requried thing are the username and password. I'd say, though, that for most of the custom-user-models I've used and seen, the standard user form in the admin would work fine -- the UserChange form, after all, shows all fields on the model, so it adapts to custom user model with more fields. It seems like an unnecessary hoop for someone to have to jump through to subclass those two forms just to change the model when we already have a get_user_model() feature for avoid that sort of thing. (And, thanks; I was changing the codebase directly to ensure that it worked when changed as such. I originally had subclassed the forms but was curious about whether it would have worked for Django to simply use get_user_model() in the contrib.auth directly. For now, I've moved back to subclassing--I'd agree it would be crazy to try to maintain a private for this. My question was about whether there was a compelling reason for Django not to use get_user_model() itself) Thanks again for thoughtful reply! On Monday, January 5, 2015 9:48:13 PM UTC-8, James Schneider wrote: > > 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" <jo...@hackbrightacademy.com > <javascript:>> 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 django-users...@googlegroups.com <javascript:>. >> To post to this group, send email to django...@googlegroups.com >> <javascript:>. >> 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/5330319a-f543-44f8-890c-15bed87c5d08%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
