Permissions Guide

Understanding Permissions

The wiki has a flexible permission system that controls who can view and edit pages and directories. Permissions can be granted to individual users or to groups.

Visibility levels

Both pages and directories have a visibility setting:

Level	Who can view
Public	Everyone, including anonymous visitors
Staff	Any signed-in staff member (people on a staff domain)
Private	Only users with an explicit grant (or the owner)

Being allowed to sign in is separate from being able to see content. Staff see Staff-level content automatically. Guests (anyone allowed to sign in who isn't staff) only see Public pages plus whatever is explicitly shared with them. A grant is *additive at any level — sharing a Staff or Private page or directory with a person, group, or whole domain* lets them in without changing the item's visibility.

Permission types

Type	What it allows
View	Read the page or directory contents
Edit	Modify content (title and body) only
Owner (shown as "Admin")	Everything Edit allows, plus managing permissions, changing visibility/editability, moving, and deleting

How permissions are checked

System owner — Has full access to everything
Page/directory owner — Can always view and edit their own items
Page-level permissions — Explicit grants on a specific page (for users or groups)
Directory-level permissions — Grants that apply to the directory and all pages and subdirectories within it (for users or groups)

How settings inherit

Every page and directory has four settings: visibility*, *editability*, search engine inclusion (sitemap), and *AI sharing (llms.txt). All four work the same way:

Inherit (default) — the setting resolves from the nearest ancestor directory that has an explicit value. The edit form shows a dropdown with the inherited value and "Provided by" the source directory, so you always know where it comes from.
Explicit override — pick any other value from the dropdown and it takes effect directly, regardless of what ancestors set.

The root directory always has explicit values since there's nothing above it to inherit from.

Setting	Options	What it controls
Visibility	Public, Staff, Private	Who can view
Editability	Restricted, Staff	Who can edit
Search engines	Yes, No	Sitemap inclusion
AI sharing	Yes, On request, No	llms.txt inclusion

When you change a directory's setting, every page and subdirectory that inherits from it automatically follows. Items with explicit overrides are unaffected.

Directories as gates

Directories act as access gates. A private directory hides its entire contents — pages, subdirectories, and all — from users who don't have access. Think of it like a folder on a shared drive: if you can't open the folder, you can't see what's inside.

Specifically:

A private directory returns a 404 to unauthorized users (it doesn't reveal that it exists)
Private subdirectories are hidden from directory listings
A private page inside a private directory requires access to both the directory and the page
A page with an explicit Public visibility override is always viewable via its direct URL, even inside a private directory (though it won't appear in the directory listing for users who can't access the directory)

Directory permission inheritance

Permission grants on a directory cascade down to all pages within it and to child directories. For example, if a user (or a group they belong to) has Edit permission on the "Engineering" directory, they can edit any page in that directory and its subdirectories.

Important

A grant on a directory reaches *everything inside it, regardless of visibility — including private pages and subdirectories, and anything added there in the future*. A grant means "let this user/group/domain in," and that can't be switched off for a specific page or subdirectory underneath. Marking a child *private* does *not* hide it from someone who has a grant on a parent.

So grant access on the narrowest* directory that should be shared — not a broad parent — and remember that anything later filed under a shared directory becomes visible to everyone it's shared with. To keep a pocket of content out, put it *outside the shared directory rather than relying on its visibility setting.

Applying permissions recursively

From a directory's Permissions* page, click Apply to children to set all child items to *Inherit and copy the directory's permission grants. You'll see two options:

Apply to direct pages only — sets inheritance and copies grants to pages directly in this directory
Apply recursively — does the same for all pages and subdirectories at every level below

This is additive — existing permission grants on child items are kept; the directory's grants are added on top. Settings are reset to Inherit so they follow the directory.

Groups

Users can be organized into groups. When you grant a permission to a group, every member of that group gets that access. This is useful for team-based permissions — instead of granting access to each person individually, grant it to a group like "Engineering" and manage membership in one place.

Groups can be managed from the Groups page.

Managing permissions

Click the Permissions link on any page or directory to manage who has access. From there you can:

Grant access to a user, a group, or a whole domain at a specific level
Remove existing permissions
See all current user, group, and domain grants at a glance

Wiki-link permission warnings

When you edit a page and it contains #slug links to private pages, the wiki will show a warning modal before saving. This is advisory — it lets you know that readers of your page may not be able to follow those links. You can still save; the warning is just for awareness.

The same modal also handles @mention permissions: if you mention a user who can't view the page, you can choose to grant them View or Edit access right from the modal.

The system owner and admins

The first user to sign in becomes the system owner. The system owner has unrestricted access to all pages, directories, and admin features.

Additional users can be promoted to admin from the Admin Management page (accessible from the gear icon in the header). Admins have:

Full access to all wiki content
Access to the Django admin panel
The ability to promote or demote other admins

The system owner cannot be demoted.

Editability

In addition to visibility, pages and directories have an editability setting that controls who can edit:

Setting	Who can edit
Restricted	Only users with an explicit edit grant (the default)
Staff	Any signed-in staff member

This is useful for pages that should be broadly collaborative — for example, team wikis or shared documentation where any staff member should be able to contribute. Guests still need an explicit edit grant.

Best practices

Use Public for documentation that should be widely accessible
Use Staff editability for pages where any staff member should be able to contribute
Use Private directories with group permissions for team spaces (e.g., grant the Engineering group Edit on /c/engineering/)
Use Apply to children after setting up directory permissions to reset inheritance and propagate grants
Use page-level permission overrides when only specific pages need different settings from their directory
Prefer group-based permissions over per-user grants — they're easier to manage as people join and leave teams