Wiki access model
This is the authoritative reference for who can see what in the Ithura wiki. The Wiki guide covers day-to-day use and has a shorter Permissions section; this page presents the whole model as one mental picture, from the outermost boundary (the space) down to the individual page, and states the exact rule a viewer has to pass.
Access is decided in layers. Each layer narrows the audience the layer above it allowed:
- Space: which wiki you are even looking at (workspace or a project).
- Collection: open to the whole space, or restricted to named people and groups.
- Page: an individual page can be made private inside its collection.
- Public share: an optional anonymous, read-only link for a single page.
1. Spaces
A wiki space is the pair (workspace, project). There are two kinds:
| Space | Who is in it | Route |
|---|---|---|
| Workspace wiki | Every member of the workspace | /{workspace}/wiki |
| Project wiki | Members of that one project | /{workspace}/projects/{project}/wiki |
The workspace wiki is scoped by workspace membership: your role in the workspace is your role in that wiki. Each project wiki is scoped by project membership, so a member who belongs to only one project sees that project's wiki and not the others. The workspace wiki and each project wiki are separate spaces with their own collections and pages.
The workspace wiki is always available. The project wiki is a Pro-plan feature: on the Free plan the project wiki route is gated and prompts to upgrade.
Everything below (collections, pages, share links) lives inside one space. A restricted collection in the workspace wiki has no bearing on any project wiki, and the reverse.
2. Collections
Inside a space, pages are grouped into collections. Every collection has one of two access settings:
- Open (the default): every member of the space can see the collection and its pages.
- Restricted: the collection and its pages are hidden from the space at large and shown only to the people and groups you name, plus the two parties who can always see it.
Two parties always see a restricted collection, with no grant required:
- The collection's creator (the member who created it).
- Any admin of the space (workspace admin for the workspace wiki, project admin for a project wiki).
Beyond those two, you open a restricted collection to others with grants, of which there are two types:
- Person grants: name an individual member. That one person gains access.
- Group grants: name a group (see Groups). Every current member of that group gains access. This is how you give a whole team access in one step, and it stays in sync: add someone to the group and they gain access, remove them and they lose it, without touching the collection.
A collection set to restricted with no grants is visible only to its creator and admins until you add people or groups.
3. Pages
A page normally inherits its collection's visibility: if you can see the collection, you can see the page. One control overrides that, tightening (never loosening) access to a single page.
Each page carries a Workspace / Private toggle in its action bar:
- Workspace (the default): the page follows normal space visibility, that is, whoever can see its collection can see the page.
- Private: the page is restricted to its owner, admins, and the users you explicitly grant on the page. When a page is private an Access button appears so you can manage those per-page grants.
Private is a per-page tightening. It applies whether the page sits in an open or a restricted collection:
- A private page in an open collection is hidden from the space even though the collection is open. Only the owner, admins, and granted users see it.
- A private page in a restricted collection is narrowed further still: being granted the collection is not enough; a viewer must also be the owner, an admin, or hold a page grant.
Page privacy does not widen access. Making a page "Workspace" inside a restricted collection does not expose it to the whole space; the collection's restriction still applies.
4. Public share links
Sharing is a separate, opt-in channel that steps outside membership entirely.
Toggle Share on a page to mint an anonymous, read-only link served at
/p/{anchor}. Anyone with the link can read that one page without logging in.
Toggle Share off to disable the link. Only a member who can edit the page may
create or remove the share link.
Sharing exposes only the single shared page, not its collection or the rest of the space, and it is always read-only.
How access is decided
For a signed-in viewer, a wiki page is readable only if the viewer clears both the collection gate and the page gate. This is enforced in one place on the server (the page-read choke-point), so every read path (the page itself, the tree, version history, comments, favorites, labels) applies the same rule and a restricted collection cannot leak through a side path.
Collection gate. The viewer passes if any one of these is true:
- the collection is open, OR
- the viewer is the collection's creator, OR
- the viewer is an admin of the space, OR
- the viewer holds a person grant on the collection, OR
- the viewer is a member of a group that holds a grant on the collection.
Page gate. If the page is private, the viewer additionally must be the page's owner, an admin, or the holder of a page grant. If the page is not private, this gate is automatically clear.
A viewer who fails either gate gets a not-found response, so a restricted collection or private page does not even reveal that it exists.
The public share link is the one path that bypasses membership: it does not use these gates at all, and serves only the single page that was shared, read-only.
Who can manage access
| Action | Who can do it |
|---|---|
| Set a collection open or restricted | The collection's creator, or a space admin |
| Add or remove a collection's person and group grants | The collection's creator, or a space admin |
| Make a page private, manage its page grants | The page owner and admins (whoever can manage the page) |
| Share a page publicly | Any member who can edit the page |
| Create, rename, delete groups; manage group membership | Workspace admins only (see Groups) |
"Space admin" means a workspace admin for the workspace wiki and a project admin for a project wiki. Managing groups is always a workspace-level, admin-only action, even when the group is granted to a collection in a project wiki.
Worked example: a Finance collection for the Finance team
Suppose Finance documents should be visible to the finance team only.
- A workspace admin creates a Finance group under Settings > Groups and adds the finance team members to it (see Groups).
- In the wiki, someone creates a Finance collection and opens its Access dialog (the lock icon on the collection).
- They set the collection to Restricted and, under Groups, add the Finance group.
Now:
- Every current member of the Finance group can see the Finance collection and its pages.
- The collection's creator and space admins can see it too, as always.
- Everyone else in the space does not see the collection at all.
- When someone joins the finance team, adding them to the Finance group grants them the collection immediately. When someone leaves, removing them from the group revokes it, with no change to the collection.
- If one Finance page holds especially sensitive numbers, its owner can toggle it Private and grant only the two people who need it. That page is then hidden even from the rest of the Finance group.