> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Usuarios y grupos > Agregar personas a una organización, qué es una invitación y por qué un grupo es casi siempre el lugar adecuado para adjuntar una política. Un usuario es una **persona** con un inicio de sesión personal. Los usuarios pertenecen a la organización a través de Workspace. Los programas desatendidos usan una cuenta [cuenta de servicio o rol](/es/iam/roles). Los usuarios pertenecen a una organización, no a una cuenta, y un usuario accede a los recursos de la cuenta a través de [Roles de cuenta asignados](/es/workspace/accounts)Las directivas de organización otorgan permisos de organización, no acceso a recursos de cuenta. Por qué esto es siempre una invitación, y lo que un `201` no promete. Directivas de organización y asignaciones de roles de cuenta para un equipo de usuarios. Lo que desprende, lo que deja atrás y cuándo surte efecto. ## Agregar un usuario Abre **Organization** → **Users**, luego **Invite users**. Ingrese una o más **Email addresses** y opcionalmente seleccione **Groups**. Cada dirección recibe su propia invitación; los resultados muestran qué invitaciones tuvieron éxito. Las invitaciones pendientes se muestran en la página **Users** con una acción **Cancel invitation**. ```bash theme={null} POST /v1/users { "email": "ana@example.com", "groups": [""] } ``` ```bash theme={null} basaltic workspace user add --email ana@example.com --groups '["platform-team"]' ``` ```go theme={null} u, err := workspace.New(cfg).AddUser(ctx, &workspace.UserAddRequest{ Email: "ana@example.com", Groups: []string{groupID}, }) ``` Cada persona elige su propia permanente [Nombre de usuario](/es/compute/ssh#choose-a-username). Las invitaciones no reservan ni anulan el nombre de usuario del destinatario. `email` es el único campo requerido. `groups` es el más útil: pone a la persona en sus grupos en el momento en que se une, así que no hay ventana donde existan sin permisos y alguien tenga que acordarse de arreglarlo. **Esta llamada siempre crea una invitación**, nunca un usuario. La respuesta es la invitación, y la persona se convierte en usuario cuando la acepta, incluso cuando ya tiene un inicio de sesión de Basaltic. No hay una ruta que agregue a alguien a una organización sin su consentimiento. Hasta que acepten, son una fila en la lista de invitaciones pendientes, no en **Users**. Se rechaza con `409` en dos casos, que vale la pena distinguir: | Mensaje de correo electrónico | Significado de la palabra | | - | - | | El usuario ya es miembro | Ya están en esta organización. | | Existe una invitación pendiente | Una invitación no aceptada para este correo electrónico está pendiente. Cancelar para volver a enviar. | Un `201` significa que la invitación fue **creada**, no que el correo electrónico llegó. El envío es el mejor esfuerzo: si el correo falla la invitación todavía existe y la solicitud aún tiene éxito, porque perder una invitación que ya fue grabada sería peor. Así que "no recibieron el correo electrónico" es un estado real, y la solución es cancelar la invitación pendiente y agregarlos de nuevo en lugar de esperar. ### Invitaciones Una invitación registra su invitante real. `invited_by.type` distingue un usuario, una cuenta de servicio o una sesión de rol asumido; los invitantes de máquina también incluyen su identidad de cuenta y no tienen una dirección de correo electrónico humana. Una invitación es la mitad pendiente de la llamada anterior. No hay un punto final de "crear invitación" separado en la API pública: agregas un usuario y una invitación es lo que obtienes cuando aún no existen. Las invitaciones pendientes se muestran en **Organization** → **Users**, debajo de los usuarios, con **Cancel invitation** en cada fila. Cuando no hay ninguna, la sección dice "No hay invitaciones pendientes". ```bash theme={null} GET /v1/invitations DELETE /v1/invitations/{invitation_id} ``` ```bash theme={null} basaltic workspace invitation list basaltic workspace invitation cancel ``` ```go theme={null} page, err := workspace.New(cfg).ListInvitations(ctx, nil) err = workspace.New(cfg).CancelInvitation(ctx, invitationID) ``` Cancelar una invitación no es lo mismo que eliminar a un usuario: se retira una oferta que nadie ha aceptado. [remove](#removing-a-user) En su lugar. ## Grupos Un grupo reúne a los principales y mantiene las políticas. Adjuntar una política a un grupo en lugar de a cada miembro es la diferencia entre un cambio y *n* cambios cuando se mueven los permisos del equipo. Abre **Organization** → **Groups** y elige **Create Group**. Ingrese un **Name** y una **Description** opcional. Las pestañas **Users** y **Policies** del grupo administran los datos adjuntos de los miembros de usuario y las directivas de la organización. ```bash theme={null} POST /v1/groups { "name": "platform-team" } POST /v1/users/{user_id}/groups { "group": "" } POST /v1/groups/{group_id}/policies { "policy": "" } ``` ```bash theme={null} basaltic workspace group create --name platform-team basaltic workspace user add-group --group basaltic workspace group attach-policy --policy ``` ```go theme={null} c := workspace.New(cfg) g, err := c.CreateGroup(ctx, &workspace.GroupCreateRequest{Name: "platform-team"}) err = c.AddUserToGroup(ctx, userID, &workspace.UserGroupAddRequest{Group: g.ID}) err = c.AttachGroupPolicy(ctx, g.ID, &workspace.PolicyAttachRequest{Policy: policyID}) ``` Los grupos contienen solo usuarios y no anidan. Las cuentas y roles de servicio usan datos adjuntos de directiva de cuenta y directiva de organización separados. Los permisos de la organización de un usuario incluyen directivas adjuntas directamente y a través de sus grupos. Una asignación de rol de cuenta a un grupo permite a sus miembros solicitar ese rol; su directiva de confianza debe aceptar a cada usuario que asuma el rol. ### Dónde adjuntar una póliza Adjunte políticas de organización a los grupos cuando la concesión describa un equipo o un trabajo. Utilice archivos adjuntos de usuario directos para excepciones individuales. Los permisos de cuenta pertenecen a las funciones y cuentas de servicio, no a los usuarios o grupos. Las políticas en línea son una tercera opción y una más limitada. Consulte [políticas administradas e integradas](/es/iam/policies#managed-and-inline-policies). ## Eliminar un usuario Abra el usuario, seleccione **Settings**, luego **Remove user** en la zona de peligro. Escriba el valor de confirmación mostrado antes de confirmar. ```bash theme={null} DELETE /v1/users/{user_id} ``` ```bash theme={null} basaltic workspace user remove ``` ```go theme={null} err := workspace.New(cfg).RemoveUser(ctx, userID) ``` Al eliminar a un usuario, se lo saca de **esta organización**. No elimina su inicio de sesión de Basaltic, que puede pertenecer a otras organizaciones, y no elimina nada que hayan creado: los recursos pertenecen a la cuenta, no a la persona que los creó. La eliminación es atómica y lleva consigo toda su huella en esta organización: las pertenencias a grupos, los archivos adjuntos de políticas, las políticas en línea, su límite de permisos y, finalmente, la propia pertenencia. Eso significa que volver a agregar el mismo correo electrónico más tarde produce un usuario con **sin permisos** — nada de eso vuelve. Si estás eliminando a alguien temporalmente, anota en qué grupos estaban primero: nada más lo hace. La eliminación termina la membresía en esta organización. Revise las sesiones de rol del usuario como parte de la desconexión; las páginas de sesión de STS de la cuenta muestran el principal de origen y permiten la revocación explícita. ## Permisos Estas APIs usan `https://workspace.basaltic.sh`. Sus acciones están en el espacio de nombres `workspace:` y deben ser concedidas a través de las políticas de la organización. | Hacer esto | Necesidades | | - | - | | Añadir un usuario | `workspace:AddUser` | | Eliminar un usuario | `workspace:RemoveUser` | | Crear un grupo | `workspace:CreateGroup` | | Agregar o quitar un miembro | `workspace:ManageGroupMembership` | | Adjuntar o separar una directiva de organización | `workspace:AttachPolicy` / `workspace:DetachPolicy` | Consulte [Permisos del espacio de trabajo](/es/workspace/permissions) para obtener información sobre las comprobaciones de recursos y las acciones de asignación de roles de cuenta.