Roles y solicitudes de acceso

Dar permisos uno por uno funciona con diez personas y se desordena con cien. Un rol es un paquete de permisos pensado para un puesto: quien entra a tesorería pide el rol de tesorería y recibe todo lo que ese puesto necesita, ni más ni menos. Eso tiene dos efectos. Primero, la solicitud es corta y la aprobación, clara: se aprueba un puesto, no veinte permisos sueltos. Segundo, la revisión posterior es más fácil: el revisor compara a la persona con el rol de su puesto y lo que sobre salta a la vista.

Las reglas de Hidrovía Andina son dos. El rol del propio puesto lo aprueba el jefe directo. Un permiso suelto, o de otra área, lo aprueban el jefe directo y el dueño de la aplicación. En todos los casos la aprobación tiene que ser de otra persona que quien pide: aprobar la propia solicitud es lo mismo que no tener control.

Compara en solicitudes la columna solicitante con aprobador_jefe.

Un rol que concede demasiado se convierte en el problema que se quería evitar. Para saber cuánto da un rol hay que contar sus permisos en la tabla rol_permisos, una fila por permiso. Cuenta los del rol de analista de pagos.

Aprobar una solicitud y otorgar lo aprobado son dos pasos distintos, y entre uno y otro puede pasar cualquier cosa: un administrador que asigna el rol equivocado, un formulario que arrastra un permiso extra. La tabla aprovisionado guarda lo que quedó otorgado junto a lo que se pidió. Si no coinciden, alguien tiene un permiso que nadie aprobó.

Pasa mucho: el jefe aprueba por un mensaje en el chat, el administrador lo recibe y asigna el permiso. La persona que pide tiene razón, el jefe también, y aun así falta algo: la aprobación no quedó donde se puede mostrar. Para una campaña o una auditoría, un chat que se borra o se pierde no sirve como evidencia de quién aprobó y cuándo.