On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote: > > Moving them into another module won't make much difference as their > definition requires Permission and Group and therefore they'd still need to > import Permission and Group. We'd need an "AbstractAbstractBaseUser" which > would be silly. > > AbstractBaseUser doesn't require any models from contrib.auth (as opposed to AbstractUser, which inherits PermissionsMixin), and I'm fine with leaving PermissionsMixin in models.py since it does require Group and Permission.
Of course, there is no requirement to use AbstractBaseUser for your custom > model at all, though this does result in some otherwise unnecessary code > duplication. I would say your choice is either two empty tables in your > database, or code duplication between Django's source and your custom user. > Personally I'd prefer the former. > Very true, but it seems like AbstractBaseUser was designed to be used by systems not wanting Django's permission structure. It's even documented[1] how to make AbstractBaseUser subclasses work with the admin. I can live with either wart (copying code or empty tables) if need be, just wanted to explore some alternatives. I'll open a ticket. [1] https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#custom-users-and-django-contrib-admin -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/297c3eb4-7832-424a-a269-4af471eae23a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
