Page permissions for users

Hi,

I have questions regarding permissions:

Kirby version: 3.3.5

What I want to achieve: Have a role (editor) to have access to two specific pages (News with subpages Articles and Dates). Everything else should be hidden or at least locked.

The editor role looks like this:

/site/blueprints/users/editor.yml

title: Editor
permissions:
  access:
    panel: true
    site: true
    settings: false
    users: false
  files:
    create: false
    changeName: false
    delete: false
    replace: false
    update: false
  site:
    update: false
  pages:
    create: false
    changeTemplate: false
    changeTitle: false
    changeSlug: false
    delete: false
    hide: false
    sort: false
    update: false
  user:
    create: false
    changeName: false
    changeEmail: true
    changeLanguage: true
    changePassword: true
    changeRole: false
    delete: false
    update: false
  users:
    create: false
    changeEmail: false
    changeLanguage: false
    changeName: false
    changePassword: false
    changeRole: false
    delete: false
    update: false

First question: With the role above, the editor can still see every page (locked and not editable). When I add the wildcard *: false to pages, all pages are hidden for the editor (which I would prefer). It seems to me there are more permissions than there are documented. How can I find those?! I copied them from here: https://getkirby.com/docs/guide/users/permissions#role-based-permissions-in-user-blueprints

Fun fact: Files are always shown (locked and not editable) even when I add *: false to files. Is there a reason for that?

Next step would be to allow the editor in the subpages via the option blueprint for that specific page:

/site/blueprints/pages/news.yml

title: News
pages: true

options:
  changeSlug:
    admin: true
    editor: false
  changeStatus:
    admin: true
    editor: false
  changeTemplate:
    admin: true
    editor: false
  changeTitle:
    admin: true
    editor: false
  delete:
    admin: true
    editor: false
  duplicate:
    admin: true
    editor: false
  read:
    admin: true
    editor: true
  update:
    admin: true
    editor: true

sections:
[...]

And the subpages Articles

/site/blueprints/pages/article.yml

title: Article
preset: page
pages: false

options:
  changeSlug:
    admin: true
    editor: true
  changeStatus:
    admin: true
    editor: true
  changeTemplate:
    admin: true
    editor: false
  changeTitle:
    admin: true
    editor: true
  delete:
    admin: true
    editor: true
  duplicate:
    admin: true
    editor: true
  preview: true
  read:
    admin: true
    editor: true
  update:
    admin: true
    editor: true

sections:
[...]

The editor can now view and edit the existing pages News and Articles.
But he cannot create new pages (Articles) or upload/edit files.

Even when I try to add create: true to the permission list (which is not listed on the docs for page permissions). What am I missing?

Bonus question: Is it possible to make single fields on a page editable for specific users?

Thank you!

Yes, there is a permission called read, if you set that to false in the pages permissions, the user cannot access anything. You can also use this setting on a per blueprint basis.

No, that’s not possible, unless you use different blueprints for different user roles:

Either completely different sets: Custom blueprint for different roles

Or single blueprints: User permisions for specific page and it's subpages

There’s also other ways to limit access to pages:

  • before:hooks

  • https://github.com/sylvainjule/kirby-bouncer

  • overriding certain methods like isReadable() for fine-grained control:

    class NotePage extends Page
    {
    
      public function isReadable(): bool
      {
       
          if ($this->author()->toUser() === kirby()->user() || kirby()->user()->role()->name() === 'admin') {
              return true;
          }
          return false;
    
      }
    

}

1 Like

Thanks very much!

I ended up denying everything for the role editor (in the role blueprint) and creating separate blueprints for the pages I needed (site, news, article, events) for the editor with the plugin example you created.

It’s not the cleanest solution in my opinion, but it gave me the option to remove some parts of the pages which are not supposed to be edited and it feels quite robust.