Workspaces, teams and sharing

A workspace owns everything in Glossa: projects, the shared string graph, the glossary and rules, API keys, the plan and its usage. You get one of your own when you first sign in. Invite people into it, give each a role, group them in teams, and keep a project to a few people when it should not be visible to everyone. A person can belong to several workspaces and switches between them from the top of the dashboard sidebar.

Roles

A workspace always keeps at least one owner: the last owner cannot leave or be demoted. Nobody can give a role above their own, and admins only change roles below admin. A call above your role answers 403 forbidden with required_role.

Inviting people

Owners and admins invite from Settings → Members with an email address, a role and optional teams. The invitee gets an email with a link that works once and expires after 7 days; it opens a page that works signed out, and they join by signing in (or signing up) with the invited address. Pending invites can be resent (a fresh link) or revoked. Only a keyed hash of the link's token is stored.

Inviting, removing members and changing roles are done by a person in the dashboard; they are not available to API keys, the CLI or MCP. Agents can read the member list with list_members.

Teams

Members create teams in Settings → Teams (or with create_team) and become their maintainer. Maintainers, admins and owners add and remove team members (set_team_member, remove_team_member). Removing someone from the workspace removes them from its teams.

Sharing projects

Every project has a visibility, set from its Share dialog or with set_project_visibility:

• org (the default): every member sees it at their role. Viewers read, members push, translate and review.
• restricted: only its creator, owners and admins, and the teams and people it is shared with. Everyone else gets 404 not_found, and its keys and file paths are left out of workspace-wide lists such as search_units and list_missing_translations.

share_project gives a team or a person read (see it, pull files), write (push, translate, review) or admin (also its settings and sharing). Your access is the highest of your role, being its creator, and every grant to you or a team you are in; a viewer never gets past read. list_projects returns your access on each project, and list_project_access shows who has what.

npx @meterapp/glossa set_project_visibility --json '{"project":"ios","visibility":"restricted"}'npx @meterapp/glossa share_project --json '{"project":"ios","team":"mobile","access":"write"}'

Strings stay one graph per workspace: a sentence used by a restricted project and an open one is still translated once, and its translation is shared.

API keys, the CLI and MCP

• An API key belongs to the workspace and acts with the role of the person who created it (an owner's key acts as admin). It keeps working if that person leaves; admins see and revoke every key, members their own.
• npx @meterapp/glossa login and OAuth connectors (Claude, ChatGPT, Cursor) ask which workspace to use when you belong to more than one. With a Supabase session token, X-Glossa-Workspace: <slug> picks one per request.
• get_account returns the workspace and your role; list_members lists everyone in it.

Audit log

Membership, role, team, invite, API key, billing, settings and sharing changes are recorded with who made them (a person, an API key, an OAuth client or Glossa itself) and kept for at least a year. Owners and admins read it in Settings → Audit log or with list_audit_log. Content changes (pushes, translations, reviews) are in the activity log.