9 ms·
Configurable User Models in Django 1.5
- xster 14y agoHTML5 form tags plz Wish we can get input type="email" required instead
- pydanny 14y agoUntil HTML5 gets into core, just use django-floppyforms.
- gtaylor 14y agoI'm really looking forward to using this, but very much dreading getting us migrated over to it. I expect we'll be spending some quality time with south, and lots of mucking with our relational fields.
- amatix 14y agoWe just went through this... renaming the table is easy via south. The worst part is either ditching your historic south migrations, or rewriting them to be myusers_user, since auth_user (in our case, and typically) wasn't south-managed, so it can't be 'unmanaged'. Remember to check you can recreate an bare database, or you'll be in for nasty surprises sometime later :)
- silent1mezzo 14y agoI'm going to have a blog post going through how to migrate sometime next week. You should subscribe ;) PS I'm the author of this post.
- dikbrouwer 14y agoWe recently did this, and it's not that big of a deal. In our case, a 30-line sql script did the job (mostly related to renaming fk fields in other tables, and re-creating indexes and constraints). More than happy to share, although it's very specific to our app of course.
- streeter 14y agoI'd be really interested to hear about the actual migration. That's what I thought this article was going to be about, instead of just how to use the feature.
- hcarvalhoalves 14y agoThe whole USERNAME_FIELD / REQUIRED_FIELDS thing feels clunkier that it should be. Isn't defining REQUIRED_FIELDS redundant, since this information could be introspected from the fields?
- pydanny 14y agoI agree it's a bit clunky, but... Making REQUIRED_FIELDS figure itself out from introspection means we all risk getting hurt by unanticipated edge cases. I would rather deal with a small bit of clunk than magical code touching my user model.
- hcarvalhoalves 14y agoThe point is: what does REQUIRED_FIELDS do? Model validation? Form validation? Can you put a blank=True field on REQUIRED_FIELDS? Can you not put a blank=False on REQUIRED_FIELDS? It's duplicating behavior in two different places, and it's not entirely clear what it does, or what overrides what. This is much worse than introspection, because you'll have to patch Django to fix any inconsistencies instead of just changing your model definition / inheriting forms accordingly.
- pydanny 14y agoSee https://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.models.CustomUser.User.REQUIRED_FIELDS https://docs.djangoproject.com/en/dev/topics/auth/#django.co... The quick version is that it's not duplicating behavior, the documentation is simply still undergoing work. We'll try and make it a bit more clear in the days to come. The long version is that during user creation sometimes you have fields that for whatever reason are not required by the database but are required for the user to enter in. This is because user creation is often more complex than it seems on the surface, and there is already existing django.contrib.auth.views that need this sort of configuration. REQUIRED_FIELDS gives you the control to force the user to enter data while not not altering the database. Is it ideal? Not really. But having dealt with user creation through email, OAuth, OpenID, LDAP, SOAP, and worse, having this as a configurable setting is better than an auto-magic introspection. Finally, I'll return to the documentation issue. I'm officially duly noting that the documentation on this feature needs work. I've opened ticket #19402 to address this issue. See https://code.djangoproject.com/ticket/19402 https://code.djangoproject.com/ticket/19402
- camus 14y agoIs it possible now to allow easy email/password login ? Anyway i found that app user profile declouped from the admin user profile made sense too.
- freakboy3742 14y agoYes - that's the primary goal of the change. However, there's lots of other possibilities, too. The point is to make the definition of the "User" model as flexible as possible.
- arocks 14y agoCreating the admin part for the new User model is quite a bit of work. You will have to not only create a new ModelAdmin but also create new forms and/or views for all the CRUD operations.
- freakboy3742 14y agoThe amount of work involved is entirely dependent on how different your User model is. If you've got a model where the username is even similar to the normal Django User, you don't need to redefine anything - you can use the existing forms and ModelAdmin. If your model uses a different identifer field (e.g., email, rather than username), or doesn't share common fields with the default User, then yes, you'll need to redefine some forms. That shouldn't be too surprising, though -- if you've created a model that's nothing like Django's default User model, it shouldn't be surprising that you need to do some work to support it. However, you shouldn't need to redefine any views, and the forms that need redefinition are fairly simple -- a fully worked example is in the docs. On top of that, those forms and ModelAdmin definitions should be extremely reusable - it will be easy to package an "email-based" user model for reuse between projects.
- arocks 14y agoI was trying to extend AbstractUser with just one extra field and realised that it was not easy. But then you are correct that it is how rest of Django works.