FactuGES_ERP/modules/identity/README.md
david a4f82decc6 feat(companies): implement update current company use case and associated controllers
- Add UpdateCurrentCompanyUseCase to handle company updates.
- Create update-current-company.controller.ts to manage update requests.
- Implement validation and mapping for update requests using Zod.
- Add tests for the update use case and controller to ensure functionality.
- Introduce error handling and feedback state management for company details settings.
- Create utility functions for error normalization and feedback state resolution.
- Implement tests for error handling and feedback state utilities.
- Ensure nullable fields are handled correctly in DTOs and forms.
2026-08-17 15:49:11 +02:00

124 lines
3.1 KiB
Markdown

# `modules/identity`
`identity` es el runtime nuevo de autenticación, sesión y acceso por memberships del ERP.
## Documentación canónica relacionada
- API de autenticación: [`../../docs/architecture/identity-auth-api.md`](../../docs/architecture/identity-auth-api.md)
- Contexto tenant y middlewares públicos: [`../../docs/architecture/tenant-context.md`](../../docs/architecture/tenant-context.md)
- Estado de migración: [`../../docs/architecture/identity-migration-status.md`](../../docs/architecture/identity-migration-status.md)
## Responsabilidades
Gestiona:
- `Account`
- login
- refresh
- logout
- session
- `RefreshToken`
- `CompanyMembership`
- acceso `account-company`
- roles/permisos futuros
No gestiona:
- la ficha operativa completa de empresa
- `companySlug` en auth
- el tenant dentro del access token
## Endpoints activos
```http
POST /identity/auth/login
POST /identity/auth/refresh
POST /identity/auth/logout
GET /identity/auth/session
```
El endpoint para companies accesibles es:
```http
GET /companies/available
```
Ese endpoint pertenece al flujo actual. Las reglas detalladas del flujo y los endpoints no válidos se mantienen en la documentación de arquitectura.
## Access token
El access token contiene solo identidad de cuenta.
Shape actual:
```ts
{
accountId: string;
email: string;
}
```
Las restricciones detalladas sobre claims y contexto tenant se documentan en `tenant-context.md`.
## Middlewares públicos
Los contratos públicos de `requireIdentityAuthenticated(params)` y `requireIdentityTenant(params)` se documentan en `tenant-context.md`.
En la V1 actual, `requireIdentityTenant(params)` y `companyAccess` resuelven membership activa y company activa.
No debe interpretarse como enforcement de permisos granulares o RBAC.
Código backend nuevo no debe usar:
- `@erp/auth/api`
- `mockUser`
- `requireAuthenticated` legacy
- `requireCompanyContext` legacy
## Servicios públicos
`identity` expone el servicio:
```txt
identity:general
```
Con acceso a `companyAccess` para casos como:
```ts
canAccessCompany(...)
findAccessibleCompanyIds(...)
```
Responsabilidad:
- `identity` decide qué `companyId` puede usar una cuenta según memberships activas.
- no devuelve la ficha completa de empresa.
- no decide todavía permisos granulares por operación.
Esto representa membership activa y accesibilidad tenant, no permisos por operación.
## Tenant context
`requireIdentityTenant(params)` compone:
- `identity:general.companyAccess`
- `companies:general.finder`
La validación esperada, la semántica de errores y el shape mínimo de `req.user` se mantienen en `tenant-context.md`.
Ejemplo actual relevante:
```http
PATCH /companies/current
```
usa membership activa y contexto tenant válido, no `identity:companies:update`.
## Reglas de mantenimiento
- Backend nuevo: usar `@erp/identity/api`.
- No duplicar aquí contratos que ya viven en documentación de arquitectura.
- No borrar `modules/auth` mientras existan consumidores legacy reales.
- `modules/supplier` sigue pendiente de migración si continúa usando el runtime legacy.