Construir mi booking

Roles y Permisos

Acceso, ajustado exactamente a la medida.

Cada organización construye sus propios roles a partir de un catálogo de permisos granulares, y puede restringir a un solo agente a productos o colecciones específicas, de forma dinámica, sin entregar nunca más de lo previsto.

  • 28 permisos Desde gestionar usuarios hasta canjear tickets, cada uno se otorga completamente por separado
  • Alcance dinámico Añade un producto a una colección ya asignada, y un agente restringido lo tiene de inmediato, sin ninguna reconfiguración
  • Reverificado en vivo Revocar un permiso en plena sesión aplica de inmediato, no en el siguiente inicio de sesión

Cuatro piezas de control de acceso.

Cada una acota lo que una persona puede hacer o ver, sin acotar lo que puede hacer la plataforma.

01

Un catálogo, no un interruptor

Usuarios, productos, precios, disponibilidad, impuestos, reservas, tickets, reportes, leads, soporte y claves de API tienen cada uno su propio permiso dedicado, así que un rol se construye con exactamente las piezas que necesita.

02

Acotado por producto o colección

Más allá del permiso en sí, un agente individual puede limitarse a productos o colecciones específicas, para un equipo regional, un solo recinto, o una marca dentro de una operación más grande.

03

Un alcance que se mantiene al día por sí solo

Restringir a alguien a una colección, no a una lista individual de productos, significa que un producto añadido a esa colección después se le vuelve visible de inmediato, sin que nadie tenga que volver a actualizar la asignación.

04

Ventas y soporte, separados a propósito

leads.view y support.view son dos permisos distintos, así que una persona puede gestionar oportunidades comerciales sin ver nunca los tickets de soporte técnico, o al revés.

Así se decide realmente el acceso

Cinco pasos, desde que se define un rol hasta que un solo clic se permite o se bloquea.

  1. 1

    Un rol se construye a partir del catálogo

    Una organización crea sus propios roles y les asigna exactamente los permisos que cada uno necesita, a partir de una lista fija y versionada, nunca de un campo de texto libre.

  2. 2

    Un usuario puede acotarse por debajo de su rol

    Más allá de los permisos del rol, un usuario puede además restringirse a productos o colecciones específicas, acotando qué puede ver y sobre qué puede actuar dentro de lo que su rol ya permite.

  3. 3

    Cada listado respeta las dos capas

    Los listados, el panel y las consultas operativas filtran siempre por el permiso y el alcance de producto juntos, nunca solo por uno de los dos.

  4. 4

    Un cambio de alcance se revalida, nunca se confía a ciegas

    Actualizar el acceso de productos de alguien reverifica cada id contra lo que realmente permite la organización, y contra el propio acceso del administrador que hace el cambio, cerrando la puerta a una solicitud manipulada que intente otorgar más de lo previsto.

  5. 5

    Un permiso revocado actúa de inmediato

    Las acciones sensibles reverifican permisos en tiempo real dentro de la misma sesión activa, así que quitarle acceso a alguien en plena sesión surte efecto enseguida, no solo la próxima vez que inicie sesión.

Cómo se ve restringir a un usuario, en la práctica

Un usuario, una lista de ids de producto, una lista de ids de colección. Enviar las dos listas vacías es cómo se elimina una restricción por completo, no una forma de dejar a alguien fuera.

PUT /admin/users/{user}/product-access
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
{
  "user_id": 482,
  "product_ids": [
    118,
    119,
    204
  ],
  "collection_ids": [
    7
  ],
  "scope": "restricted"
}
200 Acceso actualizado

Una lista vacía es cómo se elimina una restricción, no un error

Enviar sin ids de producto y sin ids de colección no deja a un usuario fuera de todo: elimina la restricción por completo y lo devuelve a ver todos los productos de la organización, igual que cualquier otro compañero sin restricciones. Restringir a alguien a cero productos no es un estado que el sistema intente representar como algo propio, a propósito, para evitar un estado separado y fácil de usar mal que en silencio significaría "no ver nada".

Preguntas frecuentes

Sí, asignándolo a una colección en lugar de a productos individuales. Un producto añadido a esa colección después se le vuelve visible automáticamente, sin necesidad de volver y actualizar nada.

Sí, para las acciones sensibles. Los permisos se reverifican en tiempo real contra la misma sesión activa, así que un permiso revocado deja de funcionar de inmediato, no en su siguiente inicio de sesión.

Sí. leads.view y support.view son dos permisos completamente separados, así que un rol puede tener uno sin el otro, manteniendo separadas las bandejas de los dos equipos aunque ambos corran por el mismo sistema.

Cada id de producto o colección en un cambio de alcance se revalida contra lo que realmente tiene la organización, y contra los propios productos accesibles del administrador que hace el cambio, antes de guardar nada. Un payload manipulado con un id que no cuadra simplemente se rechaza.

Veintiocho, cubriendo desde gestionar usuarios y rotar claves de API hasta canjear un solo ticket en la puerta, cada uno otorgable completamente por separado.

Más reservas. Más canales. La misma calma.

Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.