4dim / Notas
Invitar dejó de ser crear
El dueño tecleaba el correo y también la contraseña inicial de su vendedor, así que durante un tiempo sabía su clave. Qué se guarda en su lugar, por qué el rol viaja dentro de la invitación, y por qué no se finge un envío que no existe.
La contraseña que sabía el jefe
Si tu software deja que un administrador dé de alta a otra persona, esta nota te enseña cuatro decisiones que separan un alta correcta de una que deja a alguien con la contraseña de otro. Cuesta una tarde arreglarlo y evita un problema que no se puede deshacer.
Así funcionaba el nuestro hasta hace poco: el dueño del negocio escribía el correo de su vendedor y también su contraseña inicial. Después se la pasaba por WhatsApp.
Hay dos problemas ahí, y el segundo es el grave.
El primero: durante un tiempo —a veces para siempre, porque mucha gente no la cambia— el jefe sabe la clave de su empleado.
El segundo es que la persona entra con una contraseña que no eligió. Y lo que no se elige, no se recuerda: se apunta.
Lo que se guarda es la intención
El cambio es más pequeño de lo que parece. En vez de crear una cuenta, se guarda la intención de crearla: «a este correo, con este rol».
Eso es todo lo que existe hasta que la persona acepta. No hay cuenta, no hay contraseña, no hay nada que robar. Se le manda un enlace, y la contraseña la pone quien la va a usar.
Ese cambio de orden trae gratis algo que antes no existía: una lista de a quién invitaste y todavía no ha entrado. Es información que el dueño necesita y que antes no tenía: si creabas la cuenta directamente, la persona que nunca entró era indistinguible de la que entra todos los días.
Por eso las invitaciones pendientes se enseñan en la misma tabla que el equipo. Quien fue invitado y no ha entrado es parte del equipo tanto como quien ya está; esconderlo hasta que acepte deja al dueño sin saber a quién le escribió.
El rol viaja dentro, y no se pregunta al aceptar
Esta es la decisión que más fácil se hace mal, porque la forma equivocada parece más amable.
Al aceptar una invitación, la pantalla podría preguntar «¿qué clase de usuario eres?». Sería cómodo. Y sería dejar que la persona invitada elija sus propios permisos.
El rol se decide al invitar, viaja dentro de la invitación, y al aceptar no se pregunta nada. La única decisión que toma quien acepta es su contraseña.
Hay un detalle más, de los que solo se ven pensando como alguien que va a intentarlo: el rol que se pone en la invitación tiene que ser de ese negocio. O de los compartidos del sistema, o de los suyos propios. Sin esa comprobación, cambiar un número en el formulario invita a alguien con un rol de la plataforma, o con uno de otro cliente.
Es el mismo principio de siempre: lo que llega de un formulario es una propuesta, no un hecho.
El enlace: largo, y con fecha de caducidad en la base
El enlace lleva 32 bytes de azar. Es largo y feo, y da igual: no es un identificador que se teclee, es un secreto que se pega. Que sea largo importa más que que sea corto.
Caduca a los siete días. Y el detalle interesante es dónde vive ese número: en el valor por omisión de la tabla, no en el código de la aplicación.
| Si la caducidad vive en… | Qué la respeta |
|---|---|
| El código de la pantalla | Solo lo que pase por esa pantalla |
| La base de datos | Todo, incluida una fila creada a mano |
En el código se nombra el número igualmente, pero solo para poder decirlo en pantalla —«caduca en 7 días»— sin repetirlo. Nombrar no es decidir: quien decide es la base.
No fingir un envío que no existe
Durante meses este sistema no sabía mandar correo. Ni uno.
La salida fácil habría sido enseñar «te hemos enviado una invitación» y confiar en que nadie lo comprobara. La que tomamos fue enseñarle el enlace a quien invita, para que lo pase por donde ya habla con esa persona —que en Colombia es WhatsApp, casi siempre—.
Fingir un envío que no existe es peor que decirlo. Quien espera un correo que no va a llegar no vuelve a intentarlo.
Y resultó que el camino «provisional» era mejor que el definitivo en el caso normal: el enlace llega antes por el chat donde ya se hablan que por un correo que hay que ir a mirar. Hoy hay correo, y la opción de copiar el enlace sigue ahí.
Qué hacer entonces
- Comprueba si tu herramienta te pide inventar la clave de otro.Si te la pide, ahora mismo sabes contraseñas que no deberías saber.
- Que el rol se decida al invitar. Si se pregunta al aceptar, la persona invitada elige sus propios permisos.
- Pon la caducidad en la base de datos. Lo que vive en una pantalla solo protege el camino que pasa por esa pantalla.
- Enseña las invitaciones pendientes junto al equipo. Saber a quién escribiste y no ha entrado es la mitad del valor.
- Si no puedes mandar el correo, dilo y da el enlace. En Colombia va a llegar antes por WhatsApp de todas formas.
Esta nota sale de nuestro trabajo en Desarrollo de Software a medida.