I do think that there's a pretty common "alternate use case" which we could support more easily. That's the use case where someone wants a User model that is either:
* exactly like the Django User model, but with e-mail address as the unique identifying field instead of username * exactly like the above bullet, but with additional fields The new 1.5 user customization makes adding fields to the user model a very trivial task, but it's still a lot of code to make e-mail addresses serve the function of usernames. You need to write the model, define USERNAME_FIELD, REQUIRED_FIELDS, and all the methods, which basically work almost identically to the auth.User reference implementation. It's also not very DRY. I was considering writing an implementation of this, which I think would see a lot of use, and putting it up on PyPI, but it seems like something that would be even better if offered as part of Django itself. Here is, I think, a way we could do it without breaking backwards compatibility: * Make an EmailBasedUser class which functions identically to User, except that email is the USERNAME_FIELD. * Make auth.User subclass EmailBasedUser, add `username` and set it as USERNAME_FIELD. User would still be AUTH_USER_MODEL. * Provide instructions in the documentation saying, "If you only want this one change, set AUTH_USER_MODEL to django.contrib.auth.EmailBasedUser What is driving me here is that I think that this is a very common use case -- "I just want email addresses to function as usernames", and Django 1.5 still seems to require a lot of code to do that. It seems like it should be a quick change -- "just change this one setting" -- and it's not. I'd be interested in actually doing this if folks on the list think it's a good idea. Best Regards, Luke Sneeringer On Feb 27, 2013, at 4:47 PM, Russell Keith-Magee <[email protected]> wrote: > > > On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun <[email protected]> wrote: > > I looked into this today with 1.5 hitting and working on a project and this > seemed relevant. > > On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote: > 1. A specification of the minimal useful interface for a User (perhaps > in the form of an abstract base model?) > > A User should not require a username. Usernames are a hideous remnant that > are impossible to justify on consumer facing websites. Authentication on > e-mail should be built-in if not the default. > > A user *doesn't* require a username. It requires a unique identifying field. > However, by default, for historical reasons, the Django's built-in User model > has a username field. The whole point of the new feature is that specifying > an alternative is now a simple activity. > 4. A migration path that meets our backwards-compatibility standards. > > I saw the configurable User model that just landed in 1.5 but for a > non-library developer this is not very useful. It looks like a very large > amount of code for a rather small function. > > It's not clear what you're suggesting here. Django has a built in User model. > That hasn't changed. You can now specify your own User model, and reuse large > parts of Django's built in parts if that is helpful in your circumstances. > What exactly is your concern here? > > Furthermore: “If you intend to set AUTH_USER_MODEL, you should set it before > running manage.py syncdb for the first time.” is somewhat prohibitive to > existing projects. “you may need to look into using a migration tool like > South to ease the transition.” is not really a solution unless it is obvious > what changes should be made. > > Well, this is a situation where we can't provide documentation, because > everyone's specific circumstances will be different. The best advice for > custom user models is "set it before you run syncdb", which is what we've > said. If you've already run syncdb, you'll need to migrate your models… but > exactly what that entails will entirely depend on what your own project has > done. > > Also I don't understand: “This example illustrates how most of the components > work together, but is not intended to be copied directly into projects for > production use.” Code that is ready for production is the point of the > documentation for me. If this isn't, I think it's a documentation bug. > > The point of that comment is that you shouldn't treat the documentation as a > cargo-cult, just copying and pasting. What is there will *work*. However, in > a real application, you need to pay attention to error messages, validation > conditions and so on. > > Yours, > Russ Magee %-) > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
