fix: version 2.5.0 -- compartir proyectos con permisos reales (Lectura/Escritura)

Bug de seguridad real corregido: cualquier usuario autenticado veia
TODOS los proyectos (listado, detalle, actividades, tareas,
comentarios, adjuntos, KPIs del panel), sin importar si era miembro.
Ahora nadie ve un proyecto ajeno sin que su dueno se lo comparta --
los roles de administracion (superadmin/admin/it_manager) mantienen
visibilidad total para soporte.

Nuevo modelo de permisos por proyecto, simple y no granular:
- Solo el dueno original puede compartir un proyecto (agregar/quitar
  miembros, cambiar su nivel) -- ni un admin del proyecto ni un rol
  global pueden hacerlo por el.
- Dos niveles: Lectura (solo ver) y Escritura (crear/editar/eliminar
  actividades y tareas -- nunca el proyecto en si: no lo borra, no
  edita sus datos, no crea proyectos nuevos).

Actividades y tareas pasan a borrado logico (antes se borraban
fisico sin poder recuperar) -- nueva papelera por proyecto con
restaurar.

Incluye tambien el filtro "Usuario" en Proyectos (probado en dev en
un paso anterior), que va de la mano con este cambio de visibilidad.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Milton Gonzalez
2026-09-25 18:19:41 -05:00
parent 9b20f85ae0
commit fda83e9dff
30 changed files with 469 additions and 140 deletions
+13 -4
View File
@@ -97,11 +97,20 @@
"eliminarlo" — se oculta de listados/dashboard, sigue en BD). Borrado físico (`DELETE`, arrastra
actividades/comentarios/adjuntos por `ON DELETE CASCADE`) solo vía `permanentlyDeleteProject`,
solo superadmin, y solo sobre un proyecto que ya tiene `deleted_at` (dos pasos, nunca directo).
- `activities.deleted_at`/`deleted_by` y `tasks.deleted_at`/`deleted_by` (desde v2.5.0): antes se
borraban físico sin poder recuperar; ahora es lógica igual que `projects` — quien tiene permiso
de Escritura en el proyecto puede eliminarlas y restaurarlas (`POST .../restore`), sin borrado
físico ni endpoint de purga definitiva (no hizo falta, a diferencia de `projects`).
- `project_members.role_in_project`: `'owner'` (dueño, se asigna solo al crear el proyecto, nunca
se toca desde el endpoint de rol), `'admin'` (administrador **de ese proyecto puntual** — un
proyecto puede tener varios, otorgado por quien ya puede escribir el proyecto, sin importar el
rol global de a quién se lo otorgan), `NULL`/otro = miembro sin permisos de escritura (salvo que
además sea `project_lead` global, comportamiento previo sin cambios).
se toca desde el endpoint de rol), `'write'` (permiso de Escritura: crear/editar/eliminar
(lógico) actividades y tareas del proyecto — nunca el proyecto en sí), `NULL` = Lectura (solo
ver). **Compartir un proyecto (agregar/quitar miembros, cambiar su nivel) es exclusivo del
dueño** (`projects/service.js#canManageMembers`) — ni un rol global de administración puede
hacerlo por él. `'admin'` es un valor legado (de un tercer nivel "administrador de proyecto"
que ya no existe) que se sigue respetando como Escritura en filas viejas, pero no se asigna
desde la UI. Los roles superadmin/admin/it_manager ven, editan y pueden borrar (lógico)
cualquier proyecto igual que antes (soporte/supervisión) — la única acción que queda exclusiva
del dueño, sin excepción ni para ellos, es compartir/dejar de compartir el proyecto.
- Empresa asumida única (no hay tabla `companies` en el MVP).
- Producción siempre usa `192.168.222.32`. Desarrollo siempre usa `192.168.222.20`. No mezclar.
- `error_logs`: sin límite de tiempo, pero se recorta solo a los 1000 registros más recientes en