Going beyond Kirby's permissions features
Find out about ways to fine-tune and go beyond Kirby's built-in permission system in the Panel
Kirby has basically three ways to limit what users can do in the Panel:
- Create user roles with permissions for this role.
- Limit these role permissions on a per-blueprint basis.
- In additon to the last two options, you can also use
beforehooks to say "no no" to users if they try to do something they are not supposed to do.
If all of the above is not enough, there are other ways to put users in their place.
The method we show here is useful if you really need a completely different form setup for different user roles, because some roles are not supposed to read or edit certain parts of a blueprint on a tab or even down to the field level.
This implementation gives you absolute freedom, and you are not even limited to roles, but could create blueprint sets for individual users.
This method leverages Kirby's custom folder setup feature.
After Kirby is loaded, we check the user role of the current user and then assign a different blueprint folder for each user role or multiple user roles.
You need to maintain and keep in sync multiple complete blueprint sets. It might make sense to use symlinks to reuse blueprint parts across sets. Also, Kirby is loaded twice to make this work.
This method is useful if Kirby's default permission rules work for most blueprints and there are only one or very few where you need more control.
This implementation registers blueprints in a plugin, for example, a custom
home.yml for clients, and a general
home.yml for all other user roles.
You have to maintain multiple blueprints for a page type.
This method is useful if you want to limit read access to individual pages in the Panel that use the same blueprint.
Typical usecase: Editors should only be able to have access to a single parent page and the subpages they have created, not to siblings created by another user. So you are no longer limited to user roles.
To make this work, the subpage blueprints needs to have a field that stores the current user when the page is created. In this example, we modify the
author field in the
/site/blueprints/pages/note.php template in the Starterkit and disable it so that it cannot be changed.
author: type: users label: Author disabled: true
Now, whenever a user creates a new
note page, the user is automatically stored.
The second step is the page model. Create a new file
/site/models/note.php with the following code:
In this model we check if the current user is stored in the
author field or is an admin user. If the condition is true, they can access the page, otherwise they cannot.
Since we cannot use a static variable like in the original method, this might have some performance implications.
This plugin is useful if you want to restrict access of a user role to a specific page or pages (and its children) in the Panel.
Install the Bouncer plugin and follow the instructions in the documentation.
See the plugin's disclaimer. Limited to user roles.