Equipo, roles y espacios de trabajo
Quién puede iniciar sesión en el panel del organizador, los cuatro roles de ejemplo, cada permiso que comprueba la API, los espacios de trabajo entre los que cambia un miembro y cómo dar a cada miembro del equipo exactamente lo que necesita.
Para el paquete Full Stack
Cómo funciona el acceso
- El personal inicia sesión en el panel. Los asistentes tienen sus propias cuentas en el sitio web y nunca inician sesión en el panel.
- Un miembro tiene un rol, y un rol es un conjunto de permisos con el nombre
<area>.<action>, comoevents.publish. El rol es el mismo en cada espacio de trabajo al que pertenece el miembro. - La API comprueba un permiso en cada ruta del panel, muestre lo que muestre la pantalla. El panel oculta los elementos de la barra lateral, las pestañas y los botones que un rol no incluye, y una página abierta por su dirección dice "This page is not part of your role".
- Un cambio en el rol de un miembro, o en los permisos de un rol, le llega al miembro mientras tiene la sesión iniciada.
- Cada miembro llega a la primera página que su rol abre: el resumen para la mayoría, la página de control de acceso para el rol de Control de acceso.
Los roles de ejemplo
| Rol | Permisos | Barra lateral |
|---|---|---|
| Propietario | Los 29 | Overview, Events, Orders, Check-in, Venues, Reports, Team, AI assistant, Venue studio y Settings |
| Manager | overview.view, events.view, events.edit, events.publish, venues.view, venues.edit, orders.view, checkin.scan, reports.view, reports.export, leads.view, leads.edit, studio.use, ai_chat.use, ai_chat.view_models: eventos, recintos, control de acceso, informes, consultas, el estudio y el asistente, con pedidos de solo lectura; sin reembolsos, equipo, roles ni ajustes | Todo excepto Team y Settings |
| Finanzas | overview.view, orders.view, refunds.create, tickets.manage, reports.view, reports.export | Overview, Orders y Reports |
| Control de acceso | checkin.scan, solo para las sesiones que tengan asignadas | Control de acceso |
Los datos de ejemplo crean una cuenta por rol, un equipo de diez miembros más y la cuenta de asistente en el sitio web. Dejan los cuatro roles exactamente con estas listas cada vez que se ejecutan, así que un cambio que hayas hecho en uno de ellos en la página Roles se deshace con el siguiente yarn seed; los roles que creaste tú se dejan como están, y una contraseña existente nunca se restablece. Cambia todas las contraseñas, o borra las cuentas de ejemplo, antes de que el panel sea accesible desde internet. La guía de instalación lista los datos de acceso.
Todos los permisos
| Área | Permisos |
|---|---|
| Resumen | overview.view |
| Eventos | events.view, events.edit, events.publish |
| Recintos y planos de asientos | venues.view, venues.edit |
| Pedidos, reembolsos y entradas | orders.view, refunds.create, tickets.manage |
| Control de acceso | checkin.scan |
| Informes | reports.view, reports.export |
| Consultas | leads.view, leads.edit |
| Estudio de recintos | studio.use |
| Equipo | admins.view, admins.create, admins.edit, admins.delete, admins.assign_roles |
| Roles | roles.view, roles.create, roles.edit, roles.delete, roles.assign_permissions |
| Ajustes del espacio de trabajo | settings.view, settings.edit |
| Asistente de IA | ai_chat.use, ai_chat.view_models |
events.publishcubre publicar, despublicar, cancelar y archivar un evento;events.edit, crearlo, editarlo y duplicarlo.tickets.managereemite el código QR de una entrada o anula una entrada;refunds.createreembolsa entradas a través del proveedor de pago.admins.edittambién asigna miembros a las sesiones de control de acceso.
La lista se define una vez, en back-end/src/database/seeders/permission.seeder.ts; la carga inicial añade los nombres nuevos y quita los que la API ya no comprueba.
Espacios de trabajo
Un espacio de trabajo es un organizador: sus eventos, recintos, pedidos, puerta, informes, equipo y ajustes. Los datos de ejemplo crean cuatro (Northline Events, Kiln & Co., Mill Street Talks y Meadow Days), y el sitio web lista los eventos publicados de todos ellos.
- El menú Workspace al comienzo de la barra superior del panel lista los espacios de trabajo a los que pertenece el miembro, los suyos primero. El propietario de ejemplo pertenece a los cuatro; las demás cuentas de ejemplo, a dos o tres.
- Al elegir uno se recarga cada página para ese espacio de trabajo. La página de un registro (un pedido, un evento, un recinto) vuelve a su lista, ya que el registro pertenece al otro espacio de trabajo.
- Cada petición lleva la elección en la cabecera
X-Workspace-Id, y la API ignora un espacio de trabajo al que el miembro no pertenece y recurre al propio. - El rol es el mismo en cada espacio de trabajo: un rol y sus permisos se aplican en cada espacio de trabajo al que pertenecen sus miembros. La campana, las consultas y los roles no son por espacio de trabajo: siguen igual sea cual sea el elegido.
- Un miembro invitado desde el panel pertenece al espacio de trabajo desde el que se le invitó. Añadir un espacio de trabajo, o un miembro existente a otro, no es una pantalla del panel.
- Una instalación iniciada sin los datos de ejemplo tiene un espacio de trabajo, creado en el primer inicio de la API con su propietario a partir de
OWNER_EMAILyOWNER_PASSWORD, como explica Despliega Ticketory.
El equipo
/en/dashboard/teammuestra arriba los miembros del espacio de trabajo por rol, y luego la tabla de miembros, diez por página, los actualizados más recientemente primero (admins.view).- Un cuadro de búsqueda encuentra miembros por nombre o correo: un texto con
@busca en el correo, cualquier otro en el nombre, el apellido, el nombre de usuario o el nombre completo. En la API,GET /api/adminsaceptaemail,nameyphone, y cada filtro dado reduce la lista: se combinan con AND. - Invite member crea la cuenta al instante con nombre y apellido, un correo, un rol y una contraseña de al menos seis caracteres, escrita dos veces (
admins.create). No se envía nada por correo: comparte tú mismo los datos de acceso con la persona. - La fila de cada miembro edita sus datos (
admins.edit), cambia su rol (admins.assign_roles) o lo elimina (admins.delete). Remove saca al miembro del espacio de trabajo en el que estás, junto con sus sesiones de control de acceso allí; sigue iniciando sesión en sus otros espacios de trabajo, y la cuenta en sí se borra solo cuando era el último. Los pedidos, reembolsos y controles de acceso que gestionó se quedan como están. - Nadie puede eliminarse a sí mismo ("You cannot remove yourself from the team."), y un espacio de trabajo siempre conserva un propietario: eliminar al último se rechaza con "This workspace needs at least one Owner. Give the Owner role to someone else first."
- La página de un miembro lista lo que su rol puede hacer y, para un miembro de Control de acceso, las sesiones que puede escanear, marcadas y guardadas allí (
admins.edit). - Todos los miembros, sea cual sea su rol, editan su propio nombre, correo y teléfono en Settings, Profile, y cambian su propia contraseña en Settings, Security, con la actual. Ninguna de las dos acciones necesita un permiso.
El personal de control de acceso y sus sesiones
Un miembro que tiene events.edit o events.publish puede escanear entradas de todas las sesiones del espacio de trabajo. Cualquier otro con checkin.scan ve y escanea solo las sesiones que tiene asignadas; una entrada de otra sesión se rechaza con session_not_assigned. Las asignaciones se hacen en la página del miembro en el panel, o con PUT /api/admin/session-staff/:code.
Roles
/en/dashboard/roles, que se abre desde la página Team, muestra lo que puede hacer cada rol como una cuadrícula de capacidades, con un punto para permitido, algunas acciones o no permitido. Crea, renombra y elimina roles (roles.create, roles.edit, roles.delete), y concede sus permisos (roles.assign_permissions). Para dar a un miembro del equipo menos que un rol de ejemplo, crea un rol solo con los permisos que necesita y asígnaselo en su lugar.
A qué puede llegar el asistente
ai_chat.use abre el asistente con IA y no concede nada más. El asistente lee y cambia solo lo que permiten los demás permisos del miembro, los mismos que comprueban las páginas del panel: sin orders.view no puede leer un pedido, y sin leads.edit no puede cambiar una consulta. Lo comprueba de nuevo antes de cada acción, así que un permiso retirado durante una conversación se aplica a la siguiente.
Cómo llega un cambio a un miembro con sesión iniciada
Incluido con tu compra. Inicia sesión para leerlo o ábrelo en tu descarga.
La conexión en vivo que envía un cambio de rol a un miembro con sesión iniciada.