El rango de un rol se deduce de sus permisos

Si tu producto deja que cada cliente invente sus propios roles, esta nota resuelve un problema de interfaz que parece imposible: enseñar quién manda más sin tener ni idea de cómo se llaman los cargos.

En una consola de equipo quieres distinguir de un vistazo quién es quién. Un color por rol, una insignia junto al nombre.

Y aquí aparece el problema: los roles los inventa cada negocio. Uno tiene «Admin» y «Asesor». Otro tiene «Coordinador de posventa», «Practicante» y «Socio». Un tercero los llama por nombres de personas.

Una lista escrita en el código que dijera «admin manda más que asesor» sería adivinar. Y se rompería el primer día que alguien llame «Capitán» a su encargado.

La solución es no preguntarle al nombre. Se deduce de lo único que ya dice cuánto puede alguien: cuántos permisos lleva su rol.

Manda más quien puede hacer más. Es una frase que se sostiene sola cuando el negocio se invente el rol «Coordinador de posventa».

Los roles se ordenan por número de permisos, de más a menos, y esa posición decide el color. No hay ninguna lista de nombres en ninguna parte, así que no hay nada que envejezca cuando un cliente invente un cargo que nunca habíamos oído.

Es además verdadero en el sentido que importa: el color no dice quién es más importante como persona, dice quién tiene más poder dentro del sistema. Que es exactamente lo que alguien quiere saber al mirar una lista de un equipo.

Aquí está el detalle que convierte una idea elegante en algo usable, y es la clase de fallo que se descubre tarde porque parece un problema de otra cosa.

Dos roles pueden tener el mismo número de permisos. Y cuando se piden datos ordenados solo por ese número, el orden entre los empatados no está garantizado: puede salir distinto en cada consulta.

Consecuencia visible: alguien recarga la pantalla y la gente de su equipo ha cambiado de color. Nadie sabe por qué. Se reporta como «los colores parpadean» y se busca el fallo en el diseño.

La cura es de tres palabras: ordenar por permisos y después por nombre. El nombre no cambia entre consultas, así que el empate se resuelve siempre igual.

La regla general vale para cualquier lista: si ordenas por algo que puede empatar, añade un desempate estable. Si no, tu interfaz se mueve sola y parece embrujada.

Hay un escalón que no compite: el cero es del dueño, siempre. Los roles empiezan a repartirse desde el uno.

No es un privilegio decorativo, es una corrección de la propia regla. El dueño del negocio podría, técnicamente, tener un rol con menos permisos que otro. Si el color saliera solo del recuento, el dueño aparecería por debajo de su encargado, que es verdad según el sistema y falso según el negocio.

Es útil saber cuándo una regla deducida necesita una excepción: cuando hay un hecho que el sistema no puede deducir y sí conoce. Quién es el dueño es uno de esos hechos.

Último detalle, y aplica a cualquier producto que funcione en dos idiomas.

La consola habla español e inglés. Todo lo que dice el producto está en los dos. Pero el nombre del rol lo escribió el cliente, y se enseña tal cual en los dos idiomas.

Traducir «Asesor de posventa» al inglés sería inventárselo: no sabemos si esa persona diría «After-sales advisor», «Support rep» o algo propio de su empresa. Y una traducción automática de un nombre propio produce exactamente la clase de texto que hace que un producto parezca improvisado.

• No escribas una lista de cargos en tu código. Se rompe el primer día que un cliente invente un nombre.
• Deduce la jerarquía de algo que ya sabes. El número de permisos es la mejor aproximación y no envejece.
• Añade un desempate estable a toda lista ordenada. Si no, tu interfaz cambia sola al recargar y nadie entiende por qué.
• Reserva el escalón del dueño. Es el hecho que tu regla no puede deducir.
• No traduzcas lo que escribió el cliente. Ni roles, ni etapas, ni equipos.