Admin Guide

This page covers administrative features for the wiki system owner and admin users.

The system owner

The first user to sign in to a fresh wiki installation automatically becomes the system owner. The system owner:

Has unrestricted access to all pages, directories, and features
Cannot be demoted or archived
Can promote other users to admin

Admin users

Admin users have elevated privileges similar to the system owner:

Full access to all wiki content regardless of permissions
Access to the admin management pages
Ability to promote or demote other admins

Managing admins

Visit the Admin Management page (accessible from the gear icon in the header navigation). From there you can:

See a list of all users and their roles
Promote a user to admin by clicking the promote button next to their name
Demote an admin back to a regular user

Only the system owner and existing admins can access this page.

Archiving users

From the admin management page, you can archive a user to deactivate their account. Archiving a user:

Deactivates their account so they can no longer sign in
Deletes all their active sessions (logs them out immediately)
Preserves their content contributions (pages, revisions, etc.)

Archived users can be unarchived later to restore their access. This is preferable to deleting accounts since it preserves the audit trail of who made what changes.

Managing groups

Groups let you organize users for team-based permissions. Visit the Groups page to manage groups.

Creating a group:

Click New Group
Enter a group name (e.g., "Engineering", "Legal")
Click Create Group

Managing members:

From a group's detail page, use the username field to add members
Click Remove next to a member to remove them

Using groups for permissions:

Once a group exists, you can grant it permissions on any page or directory from the item's Permissions page. All members of the group inherit that access. This is much easier to manage than per-user permissions — when someone joins or leaves a team, just update the group membership.

Editing and deleting groups:

Click Edit to rename a group
Click Delete to remove a group (this removes the group's permission grants but does not affect member accounts)

Recent changes (activity feed)

Admins and staff can view a chronological feed of all recent edits across the entire wiki at Recent Changes. Each entry shows the page title, who made the change, when, and the change message. The feed is paginated (50 per page) and can be filtered to a specific user by clicking their name.

CDN caching

Public pages are served through a CloudFront CDN to anyone who isn't signed in. CDN-cached responses live for up to 30 days, but the cache is automatically invalidated whenever content changes:

Editing, creating, deleting, moving, or renaming a page or directory invalidates the affected URLs.
Each successful deploy issues a site-wide invalidation, in case templates or rendering logic changed in ways that don't show up as page edits.

For signed-in users, the CDN is bypassed entirely — every request goes straight to the origin. So the page you see when you're logged in is always fresh.

For anonymous viewers, edits propagate within ~30 seconds plus the time it takes CloudFront to apply the invalidation (usually under a minute, occasionally several minutes). If you need to verify how an edit looks to the public, sign out (or open an incognito window) — the next request you make will fetch the post-edit version once the invalidation lands.

If you ever need to force a manual invalidation (e.g. you suspect the cache is stuck), run:

python manage.py invalidate_cdn          # whole site
python manage.py invalidate_cdn /c/foo   # specific paths

The view counter shown at the bottom of each page is not served from the CDN cache — it's fetched fresh by JavaScript on each load, so the number stays accurate even when the surrounding HTML is cached.

Best practices for admins

Use groups for team-based access rather than granting permissions to individual users
Set up directory permissions with "Apply to children" to establish consistent access across entire sections
Archive rather than ignoring departed users — this keeps the wiki secure while preserving history
Keep the system owner role limited to one trusted person — it cannot be revoked
Use the Restricted editability default for sensitive content, and FLP Staff editability for collaborative pages anyone at FLP should be able to edit