On Tue, Nov 6, 2012 at 7:59 AM, ionel <[email protected]> wrote: > Hello, > > I'm trying to make a custom user model so I can login and register > with the email (instead of username). This means the email must become > unique and I don't need the username fields. I don't want to fill it > with random data, unique ids, hashes or whatnot. > > Also, I need to have the admin working. Because of this I'm forced to > use the AbstractUser instead of AbstractBaseUser.
Incorrect. I've got several examples -- and the documentation contains a fully worked example -- of a User model extending AbstractBaseUser, using email address for a login, that works with admin. I'm also using an example of a User model that uses email address as a login on a site I'm currently developing, and so far, it's working fine. > It seems to me that > this abstract is concerned with two purposes: fields and methods for > the admin and display fluff like username, email, first_name, > last_name. This seems wrong to me, there should be two abstract > models: BaseAbstractAdminUser and AbstractUser. > > The other alternative would be allowing abstract model subclasses to > override fields. Not sure about this tho, why is this disallowed in > the first place? > > What do you think ? > It's not clear to me what exactly your proposing, and how much of that stems from a mistake in your original premise. Like I said -- admin *does* work with AbstractBaseUser subclasses, and the documentation describes how to do it. If you're following that documentation and your hitting specific problems, then you may have found a bug, and I'm certainly interested in hearing what those problems are. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
