Is there a page option to enable the “+ add” permission to create a subpage?
My editor-role has tight restrictions:
title: Editor
permissions:
pages: false
When setting pages:true or pages: create:true all the hidden pages are visible in the panel! I guess it is similar to the question here: Page permissions for users
On page level I use these options:
options:
read: true
update: true
preview: true
Any ideas how to get the +add option again for the editor?
Sadly there was no feedback so far, but I have found a workaround!
by adding the first subpage and enabling the duplicate feature in its yml-page options:
options:
duplicate: true
update: true
...
I am not sure if I misunderstood the new permission system or my site structure is too nested or maybe both and I was the first hitting this combination. 
PS: My intention was not to code any hooks or use a plugin for this little unexpected behavior.
Look at the last line of Kirby Docs: Filtering pages:
Note that an “Add” button for new pages will only be available if you use either status: draft or status: all .
And it must be allowed within the active role and the active page blueprint, to “Add” a subpage.
Hi Heiner - thanks for pointing this out.
For admin role it works as expected. But when adding a new role the editor role with a policy to " basically removing all permissions" and enabling these only for a specific pages container and its subpages, then I have this issue with not being able to add a new page.
I would try it contrarily:
Don’t use this in the role blueprint but for this role in the necessary page blueprints (may be all), like the second or third example at Specific permissions in page, file, user or site options.
And think on Kirby Docs: Admins:
The admin role is mandatory and cannot be removed. Users with that role have all permissions, while other roles might have limited permissions.
I don’t know the hierarchy of the several blueprint types.
May be @texnixe can help here with this hierarchy.
My first shot was like you propose. And then it was to immersive as I would have had to change all blueprints not only the first level pages one. Otherwise another issue came along: The “Editor” is logged in and was able to do as intended, but all other pages were accessible by panel search.
Sorry, I cannot help with:
The Editor was able to search in pages that are not in his visible panel page structure. e.g. If you have a rather static site content-page you want to hide with all its containing subpages - you would have to change every single blueprint to “really” hide them.
Otherwise: when hiding only the static page (the first level or root page in panel) containing all others, it is hidden within the panel, but when using the panel search, the subpages are directly accessible and editable.
In the above mentioned other thread there is the idea of setting a specific panel root folder per user blueprint via plugin: GitHub - sylvainjule/kirby-bouncer: Restrict access of a user role to a specific page (and its children) in the panel.
(The sketch shows how I presumed that permissions behave)
I have to evaluate the use of this, as I intend to add further roles in the next weeks.
I will proceed with my workaround first and test the workflow. Thank you so much @anon77445132 !
I don’t know but may be something like My way to restrict a role can help you.
Good luck!
It would be helpful to know the structure of your site and what exactly you want to block for whom. In addition to using the permissions it might actually help to override page methods in a model. But I have somehow lost track of this thread.
Sorry for that, I guess I am in too deep into this structure at the moment and it was implemented before the new permission feature. Here a short extract on the matter and my extension plans for this editor role.
The problem here is that you cannot override setting of the role blueprint.
So if you disable all pages actions with pages: false in your editor.yml, you cannot re-enable them in a single page blueprint.
So the only way around this is to enable pages actions in the role blueprint and disable these permissions on the page blueprint level, which can be cumbersome with deep nesting.
Note that you can even reuse page options, so that would make it a bit easier to put those into every blueprint where they are needes.
Also my idea with overriding page model method would mean to create a model per page type. This is actually quite powerful because you can go beyond the limitations of user role permissions and blueprint permissions as regards conditions, but is of course more work.
Another option is to create blueprints per role either on an individual basis or a complete set:
The last option has the downside that you load Kirby twice and maintaining two complete sets of blueprints can be a pain as well unless you make good use of reusable modules.
If I understand this correct, the role blueprint is in the sense of my question above “May be @texnixe can help here with this hierarchy.” the highest level of all blueprints?
So something like My way to restrict a role can help us?
Thank you so much for stepping into again. @texnixe @anon77445132
All right, the permissions are powerfully designed, but there is no “recursive inheritation” to subpages. Might make sense as you will never know, what and how many page-types will be inside - cumbersome the other way around. Personally I hoped that I only miss a single flag like subpages: false 
For my current request I have the workaround with duplicate. When it comes to more fine grain control for this role or adding different roles i will elaborate the solutions again. I hope to have a nice solution to finally update this post.
On this page it says:
You can keep all permissions in the role files, but you can also overwrite them individually per page, file, user or the site in the corresponding blueprints. Those specific permission settings will always override the role settings.
Does that not contradict itself? Or am I misinterpreting this?
im stuck here myself. it seems role defined permissions can’t be overwritten which is contradicting to the statement in the kirby docs.
please fix this.
