Skip to content

Permissions

david-pettifor-nd edited this page Aug 10, 2026 · 1 revision

Permissions

Who can log in, edit pages, and manage site-wide data on ND Theme CMS v4.

Related: Getting-Started, Widgets, Aliases-and-Reuse, Site-Settings, Page-Tags, Events.

Staff login

  1. Sign in with a staff account (Django admin / account login your team provides).
  2. Return to the public site while still logged in.
  3. The CMS toolbar appears on pages you can edit.

If you do not see the toolbar:

  • Confirm you are still logged in
  • Confirm your account is marked staff and has permission for that page
  • Ask an admin to check page permissions (below)

LOGIN_URL points at the site account login (account_login). Use the login path your team documents for editors.

Page-level CMS permissions

This site runs with CMS_PERMISSION = True. That means access is not only “staff or not” — django CMS can grant or deny edit rights per page (and sometimes per language or per group).

Practical guidance for editors

  • You can edit pages your group is allowed to change. Sibling pages in the tree may be off-limits even if you can edit the parent.
  • If Create, Page settings, or Structure controls are missing, you likely lack permission for that action or page — not a broken toolbar.
  • Creating a new page usually inherits permission patterns from how your admins set up groups. Do not assume every editor can publish anywhere in the tree.
  • Saving still goes live immediately on pages you can edit. Permissions control who may save, not whether a draft step exists.

Practical guidance for admins

  • Prefer group-based page permissions over one-off user grants so onboarding is repeatable.
  • Give content editors rights on the sections they own (for example News, Events, People) rather than the entire tree when possible.
  • Superusers and global CMS permissions bypass per-page limits — use those accounts sparingly.
  • After changing permissions, have the editor log out and back in (or refresh) before troubleshooting “missing toolbar” reports.

Exact screens live under Django admin / CMS permission UIs for users, groups, and pages. Coordinate with your technical admin for group setup.

Admin-only models

Some data is not edited as page widgets. Staff with Django admin access manage it in the admin site. Typical editors may only consume this data through plugins.

Settings

Site-wide key/value settings (site name, contact, feature flags, and similar). See Site-Settings.

Field Options Notes
Key Text Unique identifier; usually read-only in admin after creation.
Setting type Text, True/False, Page Controls how the value is interpreted.
Value Text Used for Text and True/False types.
Enabled On / off Turn a setting off without deleting it.
Page CMS page Used when Setting type is Page.

Ordinary page editors do not change these from the CMS toolbar.

Events

Calendar/event records that power legacy event listings and related admin tools. See Events.

Field Options Notes
Name Text Required display name.
Start / End Date and time Optional.
Location Text Optional.
Map link URL text Optional.
Page Linked CMS page Optional association.
Series / Recurring Related admin objects Managed in admin; bulk actions may exist.

On the page itself you still place listing widgets such as Widgets-Legacy#Events Insert or Widgets-Legacy#Event List. Creating and maintaining the underlying Event rows is an admin task unless your workflow says otherwise.

Tags (Page tags)

Shared tags for filtering, search categories, and archive categories. See Page-Tags.

Field Options Notes
Tag Text Unique label.
Search category On / off Whether the tag behaves as a search category.
Archive category On / off Whether the tag behaves as an archive category.

Editors attach tags to pages via Page-Meta. Creating or renaming the tag vocabulary itself is usually admin-only.

Widgets and permissions

  • Being able to add a widget on a page does not grant admin rights to Settings, Events, or Tags.
  • Aliases-and-Reuse may have separate edit rights; treat widely used aliases carefully.
  • Prefer NDT widgets from Widgets when building content you are allowed to edit.

Checklist when someone “cannot edit”

  1. Are they logged in as staff?
  2. Does the toolbar appear on any page?
  3. Does it appear on the parent page but not the child?
  4. Can a known admin edit that same page?
  5. If yes for admin only → fix page/group permissions, not the theme.

Clone this wiki locally