AbstractUser hierarchy and email-based-users

[Hugo Osvaldo Barrera]

Hi,

I've worked on several apps where users don't have a username, and
instead require a unique email. Every time, I've used a similar custom
user model which extended AbstractBaseUser, PermissionsMixin. I then had
to copy-paste several fields from AbstractUser into my custom user
(either because they're always used, or required by the admin).

There are other hacks, and workarounds for email-based accounts (when a
project doesn't want/need usernames), and I feel that there's room for
improvement here (rather than just recommending some other hack).

Currently, the User class hierarchy is something like

... > AbstractBaseUser > AbstractUser > User

If a project does not want their Users username-based, they need to
extend from AbstractBaseUser (and PermissionsMixin), and copy some
functionality from AbstractUser. This is a pretty common scenario, and a
quick search on SO will prove lots of people come across this scenario.

I'd like to propose moving is_active, is_staff, email_user, and a few
other fields to a Mixin. Then, have AbstractUser extend this mixin too.
This does not affect our current User model, but allows custom user
models to simply extend this mixin and have admin-compatible User right
away.

With this change, and some updates to the documentation, this would
remove a lot of burden for maintainer of custom user models where
system's don't require/want username.

I'm willing to work on this too (especially since this would let me
clean up a lot of custom user models), but I'd like to know if these
changes would be acceptable or not, or if there's any feedback on it
first.

Cheers,

--
Hugo Osvaldo Barrera

[Podrigal, Aron]

I'm +1 on this.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1441186269.1688715.372548137.5D9044C1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

Russ tried to complete the "EmailUser" solution for 1.7, but if I remember correctly, there was some issue with testing that couldn't be easily resolved.

https://github.com/django/django/compare/master...freakboy3742:emailauth

Anyway, if that issue is still blocked, it looks like the `SimpleIdentityMixin` bit from that branch could at least be done as I think it's what you're asking for.

[Russell Keith-Magee]

On Wed, Sep 2, 2015 at 10:29 PM, Tim Graham <timog...@gmail.com> wrote:
> Russ tried to complete the "EmailUser" solution for 1.7, but if I remember
> correctly, there was some issue with testing that couldn't be easily
> resolved.
>
> https://github.com/django/django/compare/master...freakboy3742:emailauth

The issue is that you can't easily swap between user models during a
test run. You sync the tables, and all the ForeignKeys are
established; when you change User model, you need to change all those
references (and potentially change them back again after the test
run).

At the time, the only solution I could see was breaking up the test
suite so it did complete runs with different AUTH_USER_MODEL settings;
but that was a lot more than I was willing to chew at the time when
the problem can be solved by having a third party app.

The three options I can see are:

* Rework the test framework to allow multiple runs with different
AUTH_USER_MODEL settings. This will probably work, but it also means a
potentially exponential explosion of test environments, because we
don't want to make a special case of handling AUTH_USER_MODEL.

* Maybe doing something with the migrations framework to migrate
foreign keys between models. This will be complex, and probably
fragile, especially in the early days.

* Distribute this as an "official, but not part of Django core" app,
like localflavor and comments. That means the testing can be isolated
to a standalone app, and would be a good model for breaking up
Django's core into smaller pieces.

Yours
Russ Magee %-)