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
FLP Staff	Any signed-in user with an @free.law account
Private	Only users with explicit permission (or the owner)

Permission types

Type	What it allows
View	Read the page or directory contents
Edit	Modify content, metadata, and create child items
Admin	Full control, including managing permissions and deletion

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, FLP Staff, Private	Who can view
Editability	Restricted, FLP 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.

Access to a parent directory also implies access to its child directories. So if you grant someone View on "Engineering", they can also see "Engineering / DevOps" (unless that child directory is private and they have no grant on it specifically).

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:

Add user or group permissions with a specific access level
Remove existing permissions
See all current user and group 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 explicit edit permission (the default)
FLP Staff	Any signed-in user with an @free.law account

This is useful for pages that should be broadly collaborative — for example, team wikis or shared documentation where anyone at FLP should be able to contribute.

Best practices

Use Public for documentation that should be widely accessible
Use FLP Staff editability for pages where any FLP team 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