I think it's basically a bit of an ambiguous reading of that section of the documentation:
*"If you want your custom User model to also work with Admin, your User model must define some additional attributes and methods. These methods allow the admin to control access of the User to admin content:"* It's saying that the admin app uses those attributes and methods to determine access. What this means is that they are already defined in AbstractUser, but you can override them if your user has a different definition of is_staff or is_active or the permissions. If you look at the source for AbstractUser, it uses the built-in groups and permissions, just as the old User did. Don On Monday, November 5, 2012 5:22:51 PM UTC-8, Ionel Cristian Mărieș wrote: > > 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 <[email protected]> > wrote: > > 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/WD3F0iOGodwJ. 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.
