Using AbstractBaseUser without django.contrib.auth

[Dan Watson]

While trying out Django 1.8 with one of my sites that uses a custom User model (and doesn't have django.contrib.auth in INSTALLED_APPS), I noticed a few unexpected deprecation warnings:

/Users/dcwatson/Documents/Environments/reader/lib/python3.4/site-packages/django/contrib/auth/models.py:41: RemovedInDjango19Warning: Model class django.contrib.auth.models.Permission doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.

  class Permission(models.Model):

Same thing for User and Group. Is it required to have django.contrib.auth installed to use custom User models now? Seems like it would be easy enough to move AbstractBaseUser (and probably UserManager/BaseUserManager) to a separate modules and import them from django.contrib.auth.models, so sites could use them without triggering these errors. If this sounds reasonable, I can open a ticket/PR.

Dan

[Curtis Maloney]

Does your model inherit from PermissionsMixin?

If you're using Admin, or any of Django's permissions machinery, you will need django.contrib.auth in there to use the Group and Permission models.

--

Curtis

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/02f98a6f-9fbf-4c57-8285-80f3c2c3e2ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Watson]

On Wednesday, April 1, 2015 at 10:50:17 PM UTC-4, Curtis Maloney wrote:

Does your model inherit from PermissionsMixin?

If you're using Admin, or any of Django's permissions machinery, you will need django.contrib.auth in there to use the Group and Permission models.

I'm using my own permissions system, but implementing everything PermissionsMixin does (without subclassing it) so the admin still works.

[Shai Berger]

On Thursday 02 April 2015 05:50:04 Curtis Maloney wrote:
> Does your model inherit from PermissionsMixin?
>
> If you're using Admin, or any of Django's permissions machinery, you will
> need django.contrib.auth in there to use the Group and Permission models.
>

The problem is not with permissions; the problem is that you can't import
AbstractBaseUser without importing the concrete Permission, Group and User
models, because they're all in the same module.

> On 2 April 2015 at 13:47, Dan Watson wrote:
>>
>> /Users/dcwatson/Documents/Environments/reader/lib/python3.4/site-

packages/django/contrib/auth/models.py:41:
>> RemovedInDjango19Warning: Model class django.contrib.auth.models.Permission
>> doesn't declare an explicit app_label and either isn't in an application in
>> INSTALLED_APPS or else was imported before its application was loaded. This
>> will no longer be supported in Django 1.9.
>> class Permission(models.Model):
>>
>> Same thing for User and Group.

I am not sure what the proper fix should be; on one hand, you are using code
from django.contib.auth, so it makes some sense to require it to be installed.
On the other hand, that forces two redundant tables on you (Group and
Permission are not swappable).

Please do open a ticket -- my instinct is that django.contrib.auth will need
to be installed, but the impact of installing it should be minimised.

Shai.

[Marc Tamlyn]

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.

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.

[Dan Watson]

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

[Marc Tamlyn]

Apologies, I was confusing abstract base user and abstract user there. Seems your proposal should work. Have you opened a ticket?

On 2 April 2015 at 14:28, Dan Watson <dcwa...@gmail.com> wrote:

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.

[Dan Watson]

On Thursday, April 2, 2015 at 10:38:48 AM UTC-4, Marc Tamlyn wrote:

Apologies, I was confusing abstract base user and abstract user there. Seems your proposal should work. Have you opened a ticket?

I have:

https://code.djangoproject.com/ticket/24564

https://github.com/django/django/pull/4438