User · Modelo core
Propósito
User es el modelo de autenticación central de CreaRack Pro. Extiende AbstractUser de Django para añadir dos conceptos del dominio SaaS: la pertenencia a un tenant (organization) y un nivel de acceso explícito (role). Es el AUTH_USER_MODEL del proyecto (config/settings/base.py:181), por lo que todas las FK a usuarios en el proyecto referencian esta clase.
Contrato
Campos (añadidos a AbstractUser):
| Campo | Tipo | Comportamiento |
|---|---|---|
organization | FK(Organization, CASCADE, null) | Tenant del usuario; None indica superusuario sin tenant |
role | CharField(20) | Choices: admin, operator, readonly. Default: readonly |
Choices de rol: [("admin", "Admin"), ("operator", "Operator"), ("readonly", "Read Only")].
Métodos públicos:
__str__— devuelve"{username} ({organization.name})", o"No Org"si no tiene tenant.
Meta: UniqueConstraint sobre email con condición ~Q(email="") — unicidad de correo cuando el campo no está vacío, tolerando múltiples registros con email="" (migración 0006_user_unique_email_constraint).
Managers: hereda objects = UserManager() de AbstractUser con create_user() y create_superuser(). Sin manager personalizado.
Dependencias entrantes
| Modelo | Relación | related_name |
|---|---|---|
SystemLog | FK(SET_NULL) | system_logs |
ScriptTemplate | FK(SET_NULL) | script_templates |
ImpersonationLog | 2 FKs CASCADE (admin, target) | impersonations_performed, impersonations_received |
ModulePermission | OneToOneField(CASCADE) | module_permissions |
TemporaryAccess | FK(CASCADE) | temporary_accesses |
StoredCredential | FK(SET_NULL) | created_credentials |
LoginLog | FK(CASCADE, null) | login_logs |
Modelos de racks, terminal, monitoring, signage referencian User vía settings.AUTH_USER_MODEL.
Dependencias salientes
core.models.Organization— FK clave para el aislamiento multi-tenant; casi toda vista filtra.filter(organization=request.user.organization).django.contrib.auth.models.AbstractUser— heredausername,email,password,is_active,is_staff,is_superuser,last_login,date_joined, grupos y permisos Django.
Ejemplos
# Creación con rol (core/api/users.py:95)
user = User.objects.create_user(
username=payload.username,
role=payload.role,
organization=org,
)
# Filtrado por tenant (core/api/users.py:66)
return User.objects.filter(organization=org)
# Check de rol en vista (core/views.py:113)
if not hasattr(request.user, "role") or request.user.role not in ["admin", "operator"]:
...
Related
entity--core--model--organization— tenant al que pertenece.entity--core--model--modulepermission— permisos granulares por usuario.entity--core--model--temporaryaccess— elevación temporal de permisos.entity--core--model--impersonationlog— auditoría de suplantación.entity--core--model--loginlog— registro de logins.concept--saas--multi-tenancy— patrón de aislamiento.
Véase también
- [[entity—core—model—organization]]
- [[entity—core—model—modulepermission]]
- [[entity—core—model—temporaryaccess]]
- [[entity—core—model—impersonationlog]]
- [[entity—core—model—loginlog]]
- [[concept—saas—multi-tenancy]]
Referenciado desde
- Agente · dev-core
- Auditoría Suprema 2 · Tanda 1 (core) — cerrar gates de permiso que faltaban
- Cierre del formulario de registro built-in de allauth
- Django Admin — Referencia Rápida
- Django Admin Console Guide - CreaRack Pro
- El email de bienvenida ya trae un enlace que funciona
- Multi-tenancy con PostgreSQL Row Level Security
- Multi-tenancy en CreaRack Pro
- Organization · Modelo core
- Passkeys / Biometric Authentication - CreaRack Pro
- Raíz R6: Fallback silencioso a primer tenant permitía lectura/escritura cross-tenant (CERRADO)
- Servicio send_welcome_email — email de bienvenida con enlace de set password
- Servicio signup-activation — flujo de registro de nueva organización
- Setting SITE_URL — URL base pública para emails y enlaces