Permisos Arcanos: el todopoderoso rol Manager en Cotalker (parte 2)
En cada workflow de Cotalker, existen hechiceros capaces de hacer y deshacer todo a su antojo. Magos privilegiados que son conocidos por poseer un conjuro innato: El rol de Manager, o también conocido como "la llave maestra", ya que nos permite abrir todas las puertas, levantar cada restricción y permite ejecutar rituales que otros solo pueden imaginar.
En este artículo exploraremos cómo otorgar a los mismísimos portadores del rol Manager la facultad de moldear el flujo a voluntad, utilizando distintas técnicas de permisos y bypasses. Prepárate para descubrir cómo este poder puede ahorrarte incontables clicks, siempre y cuando lo domines con respeto.
Antes de comenzar, recuerda que este es el segundo tomo de “Permisos Arcanos”, donde en la primera parte detallamos la gestión de roles y permisos en Cotalker. Si aún no conoces ese hechizo base, te invito a leerlo aquí:
Esteban Tejeda
Capítulo 1: El conjuro de la Llave Universal. Acceso total a todos los formularios
El primer hechizo del Manager es también el más evidente: abrir cada formulario existente, sin importar para quién se creó o con qué propósito fue creado.
Su implementación es casi trivial: basta con asignar el rol de Manager en la sección "Roles de acceso" de cada formulario. Con ese único gesto, cualquier usuario que posea este rol podrá atravesar todas las puertas del flujo y explorar cada formulario, presente y futuro, sin restricciones adicionales.
En el caso de este ejemplo, el rol Solicitante es el único autorizado para ver un formulario. Como administradores, si quisiéramos probar ese mismo formulario, estaríamos bloqueados y no podríamos visualizarlo. Por eso, añadir siempre el rol Manager es esencial: garantiza que los implementadores y administradores puedan probar y auditar cualquier formulario sin quedar atrapados fuera del conjuro.
Capítulo 2: El velo avanzado y el permiso form-bypass. Revelar las vistas de desarrollador
Por si no lo sabías, los formularios de Cotalker esconden un nivel de magia más complejo: el modo desarrollador (developer mode). Cuando se activa, aparece un nuevo campo para ingresar código JavaScript que evalúa reglas de negocio específicas y decide si el formulario puede visualizarse o no.
Imagina este escenario real: Una empresa quiere que sus empleados envíen un formulario solo los días lunes, para que el jefe de área pueda conocer cómo fue su fin de semana y cómo se siente cada uno al iniciar la nueva semana laboral. Con el developer mode, la condición podría verse así:
function run() {
const day = new Date().getDay();
if (day === 1) return [{ cmd: 'HIDDEN', value: false }]
return [{ cmd: 'HIDDEN', value: true }]
}Ahora, este formulario será visible solo los días lunes, pero ¿qué pasa ahora si nosotros como administradores queremos enviar este formulario para hacer pruebas?, ¿tendremos que esperar a cada día lunes para poder probarlo? La alternativa de borrar o comentar el código condicional es engorrosa e ineficiente.
Para esto, debemos crear un nuevo permiso especial con el prefijo form-bypass. Cuando un usuario porta este talismán (normalmente parte del rol Manager), el conjuro del developer mode pierde poder. En otras palabras, puede saltarse cualquier restricción de visualización, sin alterar las reglas de negocio originales.
¿y cómo se hace esto? Implementando un bypass en el código. El developer mode permite añadir contextos, que otorgan acceso a información de la tarea en ejecución o del usuario que abre el formulario. Necesitamos justamente ese contexto del usuario para extraer sus permisos y comprobar si posee el form-bypass. Lo que nos da algo similar a esto:
function run() {
const userSelf = context["user#self"];
const userPermissions = userSelf.permissionsV2;
const hasBypass = userPermissions.includes("ordenes-compra:form-bypass");
if (hasBypass) return [{ cmd: 'HIDDEN', value: false }]
const day = new Date().getDay();
if (day === 1) return [{ cmd: 'HIDDEN', value: false }]
return [{ cmd: 'HIDDEN', value: true }]
}En Cotalker se vería así:
Esta habilidad es clave para administradores e implementadores, ya que nos permite probar formularios en entornos productivos sin tener que modificar o comentar el código condicional y desbloquear rápidamente formularios críticos en casos de soporte o incidentes.
Si quieres saber más detalles sobre el developer mode te dejaré un link con la documentación al final de este post.
Capítulo 3: Pregunta desencadenada. Liberar restricciones por rol en las questions
Al igual que los formularios poseen un developer mode, las questions dentro de un formulario también esconden un segundo nivel de alquimia. Cada pregunta tiene un apartado especial llamado “automatización”, y dentro de él viven distintos tipos de hechizos. Para este caso nos centraremos en uno: el preload.
El preload se ejecuta apenas se abre el formulario y su función principal es precargar valores en los campos. Pero su magia no termina ahí: también permite marcar campos como solo lectura (read-only), precargar otras questions e incluso realizar cálculos previos a la interacción del usuario.
Imaginemos este caso real: Un usuario ingresa un SKU en el formulario, haciendo que automáticamente se precarguen los campos de categoría, nombre y stock como solo lectura.
Hasta aquí, todo bien, pero como sabemos, el cliente siempre solicita cambios de último momento y ahora requiere que los usuarios con el rol "Órdenes de Compra: Solicitante" puedan editar el stock, mientras que el resto no.
Fácil de resolver, pero surge otro problema: Si queremos probar como administradores, no podríamos, porque solo el Solicitante tiene ese privilegio.
Aquí es donde volvemos a usar la técnica del bypass, pero con un leve cambio: En lugar de hacerlo por permiso (como en el capítulo anterior), esta vez lo haremos por rol. Es una solución ideal cuando necesitamos un control de más alto nivel y no queremos otorgar permisos adicionales.
El plan es este: Obtener la información del usuario dentro del context de la question y luego comprobar si su rol es Manager, sin duplicar reglas ni modificar la lógica de permisos.
En este caso, el contexto del usuario no nos entrega los nombres, sino que solo los IDs de los role. La mejor forma de afrontar esto es crear un diccionario que junte los nombres de roles y sus IDs respectivos. Así podemos evaluar si el usuario es, por ejemplo, Manager o Solicitante.
function userCanBypass(userRoles) {
const ALLOWED_ROLES = {
Manager: "68aff0a25341b795aa257ec2",
Solicitante: "68d4c8692931747471484689",
};
const allowedRoleIds = Object.values(ALLOWED_ROLES);
return userRoles.some(roleId => allowedRoleIds.includes(roleId));
}
El lado izquierdo del diccionario (Manager, Solicitante) es solo referencia, lo importante son los IDs, que corresponden a cada rol en Cotalker.
https://web.cotalker.com/admin/accessroles/edit/68aff0a25341b795aa257ec2El último bloque de caracteres es el ID.
Ahora que podemos saber si el usuario tiene un rol permitido, lo integramos en el preload de la question haciendo el bypass:
function run() {
const userMe = context["user#me"];
const userAccessRoles = userMe.allAccessRoles;
const canBypass = userCanBypass(userAccessRoles);
if (!canBypass) return [{ cmd: "SET_READONLY", result: "true" }];
return [{ cmd: "SET_READONLY", result: "false" }];
}Si lo queremos ver desde Cotalker:
Gracias a esto, tenemos un preload que respeta las reglas para los usuarios comunes, pero otorga libertad a los roles de mayor poder. En otras palabras, un bypass por rol, perfecto para los hechiceros con título de Manager.
Si quieres saber más detalles sobre los questions exec te dejaré un link con la documentación al final de este post.
Capítulo 4: El guardián de los estados. Saltar las reglas de cambio
En la jerarquía de Cotalker, los cambios de estado son las puertas que mantienen el orden de un flujo. Normalmente, solo los formularios autorizan el paso de un estado a otro; sin embargo, hay ocasiones en que un mago de alto rango necesita mover una tarea manualmente, sin importar las reglas del tablero.
Imagina un flujo de inventario en el que cada tarea creada representa un producto. Su estado inicial es “En Almacén”, y con el tiempo, el stock de cada producto disminuye hasta que, finalmente, el sistema lo envía automáticamente al estado “Sin Stock”.
¿Qué problema tenemos con esto? El cambio de estado desde "En Almacen" a "Sin Stock" ocurre automáticamente, sin el uso de un formulario específico. Si durante las pruebas necesitamos una tarea en Sin Stock, debemos editar manualmente el asset y dejar su stock en 0 para que el cambio automático se dispare.
La solución es sencilla pero poderosa: crear un permiso especial que permita a los usuarios de permiso Manager forzar la transición de estado.
Por convención, llamaremos a este nuevo permiso con el sufijo de force-state, lo asignamos al rol Manager y añadimos un cambio de estado manual con el nuevo permiso creado.
Con este conjuro, cualquier Manager con el permiso inventario:force-state podrá mover la tarea a cualquier estado en cualquier momento, ideal para pruebas, soporte o emergencias.
Capítulo 5: El círculo se cierra
Cada capítulo de este grimorio ha sido una puerta hacia los secretos que hacen posible el control absoluto dentro de Cotalker.
Desde la Llave Universal que abre todos los formularios, pasando por los bypass de roles, cargos y estados, hemos recorrido el sendero que separa al simple usuario del verdadero Arquimago de la plataforma.
Con este último capítulo, el Grimorio de Permisos Arcanos se cierra… aunque tú, aprendiz, sabes que todo final es solo el inicio de un nuevo conjuro.
Que cada preload, cada bypass y cada cambio de estado manual te recuerden que la verdadera magia no es saltarse las reglas, sino saber cuándo y por qué hacerlo.
Referencias:
Member discussion