Top level permission #4345

Activity

1. rhukster commented on Oct 6, 2026

   

   rhukster

   on Oct 6, 2026

   Member

   More actions

   Thanks @gareins, this is a good test of the page permissions, and your attempts were close. Two things were getting in the way:

   1. The / route is the home page, so a rule on / only changed the home page. The "top level" is an invisible root page, and a regular (non-Flex) Grav 2.x site never read rules for it, so there was no way to say "nobody in this group may create top-level pages". That's now fixed: rules in user/pages/root.md apply to the top level, as they already did on Flex Pages sites. It will be in API plugin 1.0.45.
   2. A page rule covers the page and everything below it, so one rule on FOO can't say "FOO read-only, children editable". The trick that works is the authors entry: the "authors" pseudo-group is matched against the page being edited, not the page holding the rule.

   Setup that I tested (the group has api.access, api.pages.read and api.pages.write):

   user/pages/root.md, which denies create, update and delete by default for the group:

   ---
   permissions:
     groups:
       editors: '-c-u-d'
   ---

   FOO's page frontmatter (Page Permissions in the editor), where editors is your group and every member goes in authors:

   permissions:
     authors:
       - jane
       - bob
     groups:
       editors: '+c+u+d'
       authors: '-u-d'

   Result: members can create, edit and delete anything under FOO, cannot edit or delete FOO itself, cannot create top-level pages, cannot edit or delete other top-level pages, and can still read everything.

   Every member of the group has to be listed in FOO's authors, otherwise they can edit FOO. Until 1.0.45 is out, you can get the same effect over the API by dropping the group's api.pages.write (keep api.pages.read) and leaving the root file out, but then Admin2 hides the New Page button.
2. rhukster

   closed this as completedon Oct 6, 2026