Sharing and access | Wiele docs

Access in Wiele has two layers. The organization decides who is a member and who administers. Content access decides who can read or change which files.

Organization roles

Role	Can
`owner`, `admin`	Invite and remove members, change roles, manage billing, retention and workspace visibility, and see every workspace and copy in the organization.
`member`	Belong to the organization. Membership alone gives no access to files.

Invite someone to the organization:

wiele org invite anna@example.com --role member

They get an email with an invitation ID and accept it with wiele org invitations accept ID after signing in, or through the web app. On the Starter plan an organization has at most 3 members; agents don't count.

Content roles

Role	Can
`read`	List, read and download files. Make their own copy and change files there.
`write`	Everything `read` can, plus push to main and merge copies into main.
`admin`	Everything `write` can, plus manage access to the path and delete whole folders.

Roles come from two places:

Workspace visibility. New workspaces are private. A public workspace lets every organization member read it, or write it with --member-access write. A private workspace is visible only to people with a grant inside it, and to owners and admins. Only owners and admins change visibility.
Grants. A grant gives one person a role on a workspace, a folder or a single file. A folder grant covers everything under it. The highest role that applies wins. There are no deny rules.

People see only what they can read. Listings, history, comparisons and downloads leave out everything else, and a copy with changes outside your access says so without showing them.

Invite a person straight to one or more paths. If they aren't a member yet, the invitation makes them one:

wiele access invite anna@example.com --path client-work:/acme --role write

Repeat --path for up to 20 paths. To give an existing member a role on a path, use the path's resource ID from wiele stat:

wiele stat client-work:/acme
wiele org show                       # shows the policy epoch
wiele access grant RESOURCE_ID --workspace WORKSPACE_ID --user USER_ID --role read --epoch EPOCH

Check who has access

wiele access list client-work:/acme                       # direct grants on a path
wiele access explain client-work:/acme --user anna@example.com

explain shows the person's effective role and every grant behind it. Without --user it explains your own access.

Make a workspace public or private

wiele workspace show WORKSPACE_ID
wiele workspace visibility public --workspace WORKSPACE_ID --member-access read --epoch EPOCH

A copy (branch) is public by default. Everyone who can read its files can see it, read-only. Make it private to limit it to collaborators, or let collaborators write:

wiele copy acme-rewrite --visibility private
wiele copy acme-rewrite --collaborator-access write

Whoever creates a copy is its admin, even with only read access to the files. Copy rights never extend to main. Merging needs write on every changed path in main.

Removing access

wiele access revoke RESOURCE_ID --workspace WORKSPACE_ID --user USER_ID --epoch EPOCH
wiele org members remove USER_ID --expected-version VERSION

Removing access stops new requests at once and pauses that person's background sync. It can't delete files they already downloaded.

Policy epochs and versions

Access changes take an --epoch: the organization's policy epoch from wiele org show or wiele access show. If someone else changed access in between, your command fails instead of applying to a state you didn't see. Read the epoch again and retry. Member and invitation changes work the same way with --expected-version.