Departamentos en Sevastopol

Propósito

DepartmentsViewIsland mantiene la estructura departamental del tenant. Cada departamento se asocia a un código, un nombre y un resumen agregado con headcount. Los contratos vinculan empleado + departamento; las liquidaciones permiten reportes por centro de costo.

Decisiones de UX

Decisión	Motivo
Resumen pre-agregado en endpoint dedicado	GET /api/departments/resumen trae headcount y métricas por departamento — la island lo indexa por código y lo cruza con el listado. Evita N queries en cliente.
Empleados precargados	Al cambiar tenant se cargan departments, resumen y employees en paralelo. La UI puede expandir un departamento para listar sus trabajadores sin segundo viaje.
Filtro local activo/inactivo + texto	Volumen bajo; búsqueda en nombre + codigo + descripcion cubre el caso.
view:loaded dispatcher	Después de la carga inicial la island emite el evento view:loaded (patrón compartido con otras islands) para que el shell oculte el spinner global.

Datos visibles

Grupo	Campos esperados
Identificación	Código, nombre, descripción.
Estado	Activo / inactivo.
Resumen	Headcount (trabajadores asignados al departamento).

Endpoints

Método + ruta	Uso
GET /api/departments?tenant_id=	Listado de departamentos.
GET /api/departments/resumen?tenant_id=	Headcount agregado por departamento.
GET /api/employees?tenant_id=	Listado lateral para expandir por departamento.
POST /api/departments?tenant_id=	Alta.
PUT /api/departments/:id?tenant_id=	Edición.
DELETE /api/departments/:id?tenant_id=	Eliminación.

Backend de referencia

El CRUD de departamentos vive en el repositorio del Orchestrator dentro del dominio maestro laboral. El resumen agregado se calcula en el backend para evitar consolidaciones del lado cliente.