I think you are referring to https://docs.djangoproject.com/en/dev/topics/auth/#custom-users-and-django-contrib-admin But I don't want to re-implement those if they already exist on AbstractUser. I want exactly the same permission granularity as with non-custom User so I have to pull in the groups and permission relations.
Maybe there should be a mixin with those ? And I'm not saying the admin doesn't work with AbstractBaseUser, I'm just implying that's too much code needed to get the equivalent admin features on a custom user. Maybe my usecase is not that common and I need to accept the fact, but then again, maybe not. I'm just putting it on the table. Thanks, -- ionel On Nov 6, 3:04 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Tue, Nov 6, 2012 at 7:59 AM, ionel <ionel...@gmail.com> 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
