Usuarios y roles
Un usuario es una persona que trabaja para el hotel y entra al portal
merchant.
No hay registro público. A los usuarios los crea alguien que ya tiene acceso
— un admin de plataforma, o un admin de la cuenta invitando a un colega. Un PMS
de hotel no tiene razón alguna para dejar que desconocidos se creen cuentas.
Una persona pertenece a cuentas, y tiene un rol en cada una
La identidad y el permiso son cosas separadas:
- La identidad es la persona: su nombre, correo, teléfono y contraseña.
Existe una sola vez. - El rol es lo que puede hacer dentro de una cuenta. Existe por cuenta.
Así, la misma persona puede ser admin en una cuenta y usuario corriente en otra,
y cambiar una cosa no toca la otra. El acceso a una cuenta es una membresía, no
una propiedad de la persona.
Los roles viven dentro de cada cuenta, así que una cuenta puede definir los suyos
— recepción, supervisor de Housekeeping, revenue — en vez de recibir una lista
fija.
Dos poblaciones separadas
| Quién | Entra a | Alcance |
|---|---|---|
| Usuarios del hotel | El portal merchant | Una o más cuentas, con un rol en cada una. |
| Admins de plataforma | La consola de admin | Toda la plataforma, entre cuentas. |
Son poblaciones genuinamente distintas con credenciales distintas, no un solo
sistema con un rol más grande. Un admin de plataforma no es "un usuario con más
permisos", y un usuario del hotel no se puede ascender a uno.
Por eso también hay ajustes que son solo de admin: la zona horaria de una
propiedad, su moneda, su prefijo de código de reserva y qué features tiene son
decisiones de plataforma, no del hotel. Ver
Propiedades.
Administrar el equipo
Usuarios en el portal merchant lista el equipo de la cuenta: nombre, correo,
teléfono, rol y último acceso. Invitar a alguien le manda una invitación;
quitarlo lo saca del equipo.
Dos secciones están más restringidas que el resto del portal — API keys y el
registro de peticiones son para el dueño de la cuenta o un usuario admin,
porque una key es una credencial que alcanza los datos del hotel desde afuera.
Ver Emitir API keys.
El selector de propiedad no es un permiso
Toda pantalla acotada a una propiedad actúa sobre la propiedad seleccionada
arriba. Eso es contexto, no control de acceso — cambiar de propiedad cambia
lo que se está mirando, y un usuario que alcanza la cuenta alcanza sus
propiedades.
Si uno se descubre esperando que el selector le esconda una propiedad a alguien,
esa es una pregunta sobre roles, no sobre el selector.
En la API
- Los endpoints merchant llevan la cuenta en un header
X-Tenanty la propiedad,
cuando corresponde, enX-Property. - Los endpoints de admin de plataforma se autentican contra su propio guard y no
se alcanzan con el token de un usuario del hotel. - La External API no tiene usuarios en absoluto — se autentica con
una API key que es la cuenta.
Relacionado
- Cómo se organiza Axis Pro — cuentas, propiedades y unidades.
- Propiedades — qué ajustes son del hotel y cuáles no.
- Emitir API keys — la credencial que no es un usuario.
Updated 13 days ago