History

david cf07de4836 feat: add proforma customer change evaluation utility - Implemented `evaluateProformaCustomerChange` function to assess changes in customer details for proforma invoices. - Introduced types for customer change details, blockers, field differences, and fiscal targets. - Added utility functions for normalizing text and formatting recipient information. test: add unit tests for customer payment resolver - Created tests for `CustomerPaymentResolver` to validate payment term retrieval and handling of inactive terms. - Ensured proper behavior when clearing payment terms and handling non-existent terms. test: add unit tests for customer default payment term resolver - Developed tests for `CustomerDefaultPaymentTermResolver` to verify default payment term resolution logic. - Included scenarios for creating customers with and without explicit payment term IDs. feat: implement customer default payment term resolver - Created `CustomerDefaultPaymentTermResolver` to manage default payment term resolution during customer creation. - Integrated with company finder and payment resolver services. test: add unit tests for create customer use case - Implemented tests for `CreateCustomerUseCase` to ensure correct handling of payment term IDs during customer creation. - Validated behavior when no explicit payment term ID is provided. test: add unit tests for update customer use case - Developed tests for `UpdateCustomerUseCase` to verify payment term handling during customer updates. - Ensured that inactive payment terms are not assigned and that explicit null values are respected. feat: add dependency injection for customer company services - Implemented DI for customer company dependencies to facilitate service resolution. test: add tests for customer create data utility - Created tests for `buildCustomerCreateData` to validate payment term handling based on user input.		2026-08-17 11:25:34 +02:00
..
src	feat: add proforma customer change evaluation utility	2026-08-17 11:25:34 +02:00
package.json	v0.10.3	2026-08-05 21:20:50 +02:00
README.md	feat: add proforma detail components and utilities	2026-08-05 13:17:55 +02:00
tsconfig.json	Identity -> pantalla de login	2026-07-05 13:43:13 +02:00

README.md

`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
Contexto tenant y middlewares públicos: ../../docs/architecture/tenant-context.md
Estado de migración: ../../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

POST /identity/auth/login
POST /identity/auth/refresh
POST /identity/auth/logout
GET  /identity/auth/session

El endpoint para companies accesibles es:

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:

{
  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.

Código backend nuevo no debe usar:

@erp/auth/api
mockUser
requireAuthenticated legacy
requireCompanyContext legacy

Servicios públicos

identity expone el servicio:

identity:general

Con acceso a companyAccess para casos como:

canAccessCompany(...)
findAccessibleCompanyIds(...)

Responsabilidad:

identity decide qué companyId puede usar una cuenta según memberships activas.
no devuelve la ficha completa de empresa.

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.

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.