

Configurable User Models in Django 1.5 - craigkerstiens
http://procrastinatingdev.com/django/using-configurable-user-models-in-django-1-5/#more-976

======
hcarvalhoalves
The 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?

~~~
freakboy3742
I'm the author of the feature, so I figured I should give some explanation.

REQUIRED_FIELDS is used internally in one place -- in the createsuperuser
management command. When you run that command, you are prompted for the
minimal set of fields to create a user object. REQUIRED_FIELDS is that list of
fields.

Could this be used elsewhere? Sure. A model form, for example, could use this
list as the minimal data to create a user object.

Could this be replaced with some model introspection? Possibly. On my first
pass through, this is exactly what I tried to do. And the code got messy
really quickly.

At a first approximation, any field with blank=False and no default is
essentially "required". However, what about BooleanFields? BooleanFields have
an automatically default to False, but that doesn't necessarily mean that
False is an appropriate value. And what about custom fields that use the same
"built-in default" pattern?

There's also a possible edge case where a field strictly isn't required (e.g.,
it's blankable) but from a business logic perspective, you always want to have
a value.

Ultimately, I came to the conclusion that the mess was worth it. That said,
I'm not 100% opposed to cleaning it up. Essentially, if someone can make
createsuperuser work without the need for REQUIRED_FIELDS, and the code is
robust and isn't a mess, I'm willing to look at the patch before 1.5 final.
However, I'm not planning on looking at this problem myself.

~~~
aptwebapps
"I'm the author of the feature ... "

Thank you.

------
gtaylor
I'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.

~~~
dikbrouwer
We 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
I'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.

------
arocks
Creating 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
The 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
I 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.

------
camus
Is 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
Yes - 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.

------
xster
HTML5 form tags plz Wish we can get input type="email" required instead

~~~
pydanny
Until HTML5 gets into core, just use django-floppyforms.

