>
>
>
> - I believe that we should add an AbstractEmailUser as a subclass of
> AbstractBaseUser, and make AbstractUser subclass it.
> - So, right now we have AbstractBaseUser -> AbstractUser -> User.
> - My desired hierarchy would be:
> - AbstractBaseUser
> - AbstractEmailUser
> - AbstractUser
> - User
> - EmailUser
> - I assume this is mostly intuitive, but under my proposed
> hierarchy, everything that AbstractUser has now would be moved to
> AbstractEmailUser *except for* the username field.
> AbstractEmailUser would have USERNAME_FIELD set to 'email', and
> REQUIRED_FIELDS set to empty tuple. AbstractUser would have
> USERNAME_FIELD
> set to 'username' and REQUIRED_FIELDS set to ('email',).
> - Both User and EmailUser would have the swappable Meta option set
> to 'AUTH_USER_MODEL'.
>
>
One thing to note here, is that AbstractEmailUser would have to define the
email field with unique=True in order for it to be used as USERNAME_FIELD.
This would mean that AbstractUser and User would fundamentally change so
that email has to be unique. This could definitely wreck havoc with
existing apps that don't have this requirement.
One solution would be to have an intermediate class (AbstractNamedUser or
something) that both AbstractEmailUser and AbstractUser inherit from, and
each would define their own email fields. The other would be to stub out
the email field (email = '') on AbstractEmailUser and actually implement it
in each descendent class. I like the former approach myself, since it
abstracts out name handling and would make it easier to create custom users
that handle names differently. It might make sense to put
AbstractEmailUser above AbstractNamedUser in the inheritance chain, and use
the stubbing technique too.
>
> - I would then propose taking forms that hard-declare username as a
> field (e.g. UserCreationForm, but there are others) and instead determine
> their username field using the `fields` meta option in ModelForm.
> - An example in the case of the UserCreationForm would be: fields =
> (model.USERNAME_FIELD, 'password1', 'password2')
> - There's a potential land mine in here which is that the
> `clean_username` method is much less straightforward: we'd either have
> to
> determine the method name programmatically in class construction or get
> around the issue through double-defining it. I would favor the former
> because then the form is useful without modification to more third-party
> use cases. However, this is one of the (few, IMO) cases where there
> actually is a complexity hit, and I believe this problem should be
> noted as
> a disadvantage of my approach.
>
> The clean_username method is technically unnesseccary, it just provides a
better error message than the ORM would. There might be a way to
generalize this differently. The other issue is that username is hard
coded into these forms as a regex validation. That could perhaps be moved
to the AbstractUser class itself.
>
> - I haven't looked at views as thoroughly, but I believe them to be
> more straightforward. I will do this dive soon.
>
> In my experimentation, I haven't had to touch the views at all to make
things work. I may have missed something though!
The only other part that would have to change is UserAdmin, although it may
end up being simpler just to require a custom Admin class for every custom
user model, since it seems to me abstracting that would be tricky.
-Tim
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
