Cómo separar usuarios (modelos) por administradores y clientes en Django

Me gustaría separar a los usuarios de mi aplicación Django en dos clases:
Admin (usuarios que usan Django admin) – heredar de AbstractUser
Usuario (usuarios de clientes) – heredar de AbstractBaseUser

Quiero separar estos dos tipos de usuarios porque todos los campos de AbstractUser ( is_staff , is_superuser , groups , permissions ) son inútiles para los usuarios de mis clientes y para los permisos y grupos, solo quiero implementar algo diferente. Por eso, quiero usar AbstractBaseUser .

Pero para los usuarios de administración de django, la clase AbstractUser , es simplemente perfecta y particularmente con la función de permisos.

 class Admin(AbstractUser): pass class Customer(AbstractBaseUser): pass 

Pero ahora, ¿hay una manera de precisar el modelo de usuario usado Admin para el administrador de django solamente? Y usar el modelo de Customer para el rest de mis aplicaciones.

¿Tenía que implementar esto desde cero?

 class MyUser(AbstractBaseUser): username = models.CharField(max_length=30, unique=True) first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=30) email = models.EmailField() is_active = models.BooleanField(default=False) class Admin(MyUser, PermissionsMixin): is_staff = models.BooleanField(default=True) class Customer(MyUser): # specific fields pass 

Con esta implementación, si configuro AUTH_USER_MODEL en User , los permisos no funcionarán porque el User no tiene permissions , is_superuser y is_staff .

Y si lo configuro como Admin , no podré autenticar a los Customers con django.contrib.auth .

Entonces, chicos, ¿tienen una solución a este problema?

La forma en que Django te ofrece parece ser mucho más flexible y adaptada para el futuro.

  1. Tiene un modelo de User incorporado, que puede anular. De todos modos, ese modelo tiene permisos, grupos, etc.
  2. Si necesita diferentes conjuntos de campos para diferentes tipos de usuarios, cree un OneToOne perfil OneToOne .
  3. El punto de separación entre sus administradores (en realidad, los usuarios del personal) y los clientes habituales es un atributo User.is_staff .

De esta manera, obtienes un montón de cosas interesantes (en comparación con dos modelos de usuario completamente diferentes):

  • Todo funciona fuera de la caja : los módulos contrib.auth y contrib.admin .
  • Punto de separación fácil de personalizar : simplemente anule el admin_site.has_permission() y aquí está.
  • Usted tiene la capacidad (pero no la obligación) de crear usuarios que sean clientes y administradores .
  • Puede asignar grupos y permisos (diferentes de los de sus administradores) a sus clientes. Incluso tú no lo necesitas ahora, quién sabe.

En cuanto a los inconvenientes. El único que ha señalado hasta ahora: sus clientes tendrán permisos (no utilizados por ahora). Bueno, como ellos (así como los grupos) son solo tablas separadas, los datos de sus clientes no tendrán un rendimiento de sobrecarga de almacenamiento.

Es decir, los gastos generales son insignificantes en comparación con los beneficios. Recomiendo encarecidamente quedarse con el modelo de User predeterminado de Django y extenderlo si es necesario.