Equipo, roles y permisos

Cómo funciona el acceso

• Una cuenta es cualquiera que inicia sesión. Pertenece a un espacio de trabajo mediante una membresía con un rol: Owner (exactamente uno por espacio), Admin, Member o Billing. La misma cuenta puede tener un rol distinto en cada espacio al que pertenece.
• Cada espacio de trabajo mantiene su propia matriz de roles: qué rol tiene cuáles de los catorce permisos. El propietario los tiene todos y no se puede editar, y dos de ellos, workspace.delete y roles.manage, quedan con el propietario diga lo que diga la matriz. Un espacio nuevo parte de los valores por defecto de abajo.
• La API comprueba en el servidor cada petición de espacio de trabajo: una cuenta que no es miembro recibe 404, como si el espacio no existiera, y un permiso ausente recibe 403. Un espacio de trabajo suspendido conserva toda lectura y rechaza toda escritura.
• El panel oculta las filas de la barra lateral y los botones que un rol no incluye, y una página abierta por su dirección muestra Access required.
• Un cambio en el rol de un miembro o en la matriz se aplica a la siguiente petición de ese miembro a la API. Su barra lateral y sus botones lo siguen la próxima vez que el panel lee el espacio de trabajo, como muy tarde al recargar.
• El personal de la plataforma (Platform admin y Support) es un conjunto de roles aparte que abarca todos los espacios de trabajo: consulta Administración de la plataforma.

Los roles y cuentas de la carga inicial

Forma Studio, el espacio de trabajo de ejemplo, usa la matriz por defecto. Cada rol tiene una cuenta de ejemplo que inicia sesión en el panel; la guía de instalación lista sus datos de acceso.

• workspace.read es lo que abre las filas Team, Roles y Settings, así que todos los roles, Billing incluido, ven la lista de miembros, la matriz de solo lectura y los ajustes. Los proyectos del resumen, su gráfico semanal y los proyectos que necesitan atención requieren projects.read. Su actividad reciente y la campana muestran todos los eventos a un rol que tiene projects.read o audit.read; un rol con billing.read y ninguno de esos dos (Billing, tal como se carga) ve solo los eventos de facturación, y cualquier otro rol no ve ninguno. El registro de actividad completo y su exportación requieren audit.read.
• El correo de facturación del espacio de trabajo solo se devuelve a un rol con billing.read o billing.manage.
• Forma Studio tiene 8 miembros (un propietario, un administrador, cinco miembros y un contacto de facturación) en los 10 puestos del plan Pro, con dos invitaciones pendientes y un proyecto archivado. El propietario es también administrador de un segundo espacio de trabajo, Monogram, que tiene su propio propietario, equipo, invitación y clave de API.
• yarn seed escribe la matriz de un espacio de trabajo solo cuando no tiene ninguna, así que ejecutarlo de nuevo conserva los cambios que hiciste en la página Roles. Cambia todas las contraseñas de ejemplo, o elimina las cuentas de ejemplo, antes de que el panel sea accesible desde internet.

• Instalación

Todos los permisos del espacio de trabajo

La página Roles agrupa los permisos bajo las etiquetas de abajo. La lista se define una sola vez, en back-end/src/modules/workspaces/constants/workspace-permissions.ts, con los valores por defecto de los que parte cada espacio nuevo.

La página Team

/en/dashboard/team tiene dos pestañas, Members e Invitations, cada una con una búsqueda y un filtro Role. Los miembros se listan con el propietario primero, luego por rol y por cuándo se unieron.

• La fila del propietario no tiene acciones: la propiedad se traspasa solo mediante Make owner.
• Eliminar a alguien lo saca de este espacio de trabajo al instante; sus proyectos y tareas se quedan. Nadie se elimina a sí mismo desde este menú, y un administrador puede eliminar miembros y contactos de facturación pero no a otro administrador (la API responde 403).
• Un miembro eliminado conserva su cuenta y sus otros espacios de trabajo.

Invitaciones y puestos

• Invite a member pide una dirección de correo y un rol, y lista lo que podrá hacer ese rol. A la persona se le envía por correo un enlace a /en/invitations/<token> que dura siete días; sin SMTP_HOST, el mensaje, con su enlace, se escribe en el registro de la API.
• La página de la invitación muestra el espacio de trabajo, el rol, el correo invitado (oculto en parte) y quién la envió. Aceptarla requiere haber iniciado sesión con el correo invitado: quien es nuevo crea antes una cuenta con ese correo. Una invitación para otro correo, una caducada o una revocada se rechaza con su propio mensaje.
• Cada plan tiene un número de puestos: 3 en Starter, 10 en Pro y 30 en Scale. Una invitación pendiente no usa ningún puesto; aceptarla sí. Sin ningún puesto libre, una invitación nueva se rechaza ("There is no free seat. Change the plan to invite more people."), y también aceptar una, comprobado en la misma transacción para que dos personas no puedan ocupar el último puesto a la vez.
• Resend invitation crea un enlace nuevo y una nueva caducidad de siete días, una vez por minuto como máximo y cinco veces por invitación. Revoke invitation hace que el enlace deje de funcionar.
• Se rechaza invitar a alguien que ya es miembro o que ya tiene una invitación pendiente. Cuando se agota el periodo de gracia (BILLING_GRACE_DAYS) de un espacio de trabajo con pago vencido, las invitaciones nuevas se rechazan hasta que se pague.

• Facturación y planes
• Ajustes de correo

La página Roles

/en/dashboard/roles muestra la matriz del espacio de trabajo: una fila por permiso, en los seis grupos de arriba, y una columna por rol, cada celda Allowed o Not allowed. La columna Owner está bloqueada, y las filas Delete workspace y Manage roles dicen Owner only.

• Solo el propietario la cambia. Todos los demás que tienen workspace.read la ven en solo lectura: "Only the workspace owner changes what each role can do."
• Save changes muestra primero lo que gana y pierde cada rol, luego guarda toda la matriz y escribe un evento roles.updated en el registro de actividad. Reset vuelve a la matriz guardada.
• Los cuatro roles son fijos: un espacio de trabajo no puede añadir un quinto. Para dar a alguien menos que un rol, quita el permiso a ese rol, lo que lo cambia para todos los que lo tienen.

Propiedad

• Make owner pide la contraseña del propietario, luego convierte al miembro elegido en propietario y al propietario anterior en administrador, en un solo paso. Se escribe en el registro de actividad como ownership.transferred.
• Solo el propietario elimina el espacio de trabajo, desde Settings, con su nombre y su contraseña.
• En la plataforma, una cuenta que es propietaria de un espacio de trabajo no se puede eliminar hasta que otro miembro pase a ser propietario.

Las rutas detrás de estas páginas

:workspaceId es el id público del espacio de trabajo, como org_forma. Los errores vuelven como códigos: seat_limit_reached, already_member, already_invited, resend_too_soon, resend_limit_reached, owner_protected, workspace_owner_only e invalid_password entre ellos.

• Referencia de la API

Cómo se construyen las comprobaciones de permisos