Permissions

VegaStack resolves a permission from two axes: the actor's workspace role (administration) and the access grants that reach the resource (content). The result is one of none, viewer, commenter, or editor. Access is granular per resource — a grant can land on a space, a folder, or a page — and inherits down the tree.

Workspace roles

There are only two workspace roles, and they govern administration, not content:

• admin — manages members, teams, and settings; creates and deletes spaces; and has full (editor + admin powers) access to every resource, even private ones they were never granted.
• member — an ordinary user. A member's content access is purely their grants — there is no workspace-level cap. A member with no grant on a resource has none.

Access grants

A grant (access_grants) ties a subject to a resource at a role:

• subject — a user, a team, or the workspace ("everyone").
• resource — a space, folder, or page.
• role — viewer (read), commenter (read + comment), or editor (full control: edit content, manage all sharing including the public link, delete folders/pages).

Grants are additive and inherit down the tree (space → folder → page). Adding a grant never removes anyone's access; to restrict, don't grant (or revoke).

Resolving the effective role

For an authenticated user on a page:

1. Instance admin or workspace admin → editor plus admin powers (full access everywhere).
2. Not a workspace member → none (falls through to the public gate as an anonymous visitor).
3. Otherwise the role is the strongest grant along the path — on the page or any ancestor folder/space — targeting the user, a team they belong to, or the workspace ("everyone"). No grant anywhere on the path → none.

There are no per-resource "admin" roles. editor is the top content role; space creation and deletion are workspace-admin only.

Membership and spaces

Membership = holding a space-level grant — your own, one via a team, or the workspace "everyone" grant. There is no join/leave and no separate members table.

• An "open" space is one with an "everyone" grant (a workspace-subject grant). Every member gets that level, and the space shows in everyone's sidebar.
• A space's visibility is discoverable or private:
  • discoverable — the space's name appears in Browse with no content access; an admin or editor must grant you before you can read it. There is no self-join.
  • private — invisible to non-members (a uniform 404, never listed).

Teams

A team is an admin-managed, named set of workspace members, manageable under Settings → Teams. A team can be the subject of a grant, so granting a folder to a team gives every current member of that team that role. Removing someone from the team removes the derived access on the next request.

Editing access and sharing

Anyone with view+ on a resource sees the Share sheet and can copy the link (copying never grants access — access is resolved per user). Editing the sheet is role-gated: editor+ (and admins) manage grants, discoverability, and the public link; viewer/commenter see it read-only.

Public access

Public (external) sharing is the per-resource public link, set in the Share sheet's "Anyone with the link" section: none, view, or comment, with optional password, expiry, and a "allow search engines" toggle. It inherits most-specific-wins. An off, expired, or unreachable resource yields a uniform 404, never a "this exists but you can't see it" signal. See Public links.

Audit

Access changes write to the audit log: grant create/update/revoke, public-access change, space creation/deletion, team create/update/delete, and team membership changes. Subject is the user, team, or workspace ("everyone"), plus the resolved role.