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)

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 public page is always viewable, even if its directory is private (public means public)

Pages can't be more open than their directory

A page in a private directory cannot be set to public. This prevents accidentally exposing content that the directory is meant to protect. If you try to:

Create a public page in a private directory — you'll get an error asking you to keep the page private
Edit a page to public when it's in a private directory — same error
Move a public page into a private directory — blocked with a message to change the page to private first

To make a page public, first make its directory public (or move the page to a public directory).

Default visibility

When you create a new page in a directory, the visibility defaults to match the directory. A new page in a private directory will default to private, saving you from having to change it manually.

Directory permission inheritance

Permissions 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

When you set up permissions on a directory, you can copy those permissions to all child pages and subdirectories at once. From the directory's Permissions page, click Apply to children. You'll see two options:

Apply to direct pages only — Sets the visibility and copies permission 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 permissions on child items are kept; the directory's permissions are added on top.

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.

Important constraint: A page or directory cannot be set to "FLP Staff" editability if its visibility is "Private". This prevents granting edit access to users who can't even view the content.

When you apply permissions recursively from a directory, the editability setting is also propagated to all child pages and subdirectories.

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 propagate them to existing pages
Use page-level permissions when only specific people need access to a particular page
Prefer group-based permissions over per-user grants — they're easier to manage as people join and leave teams