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:
+13
-4
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user