can only move pages if can edit parent

[diogo]

I want a user to be able to change the order of children without being able to edit the parent page. This is the scenario I have

parent: | view pages ⊠ | edit pages ◻ | create pages ◻ | add children ⊠ |

children: | view pages ⊠ | edit pages ⊠ | create pages ⊠ | add children ◻ |

The user is able to move the children if I give him permission to edit the parent, wish can is inconvenient if you need that page unchanged. Not a serious problem in this particular case, but shouldn't this behaviour be changed?

[ryan]

Have you tried creating a role that has page-sort permission on the parent template, but not page-edit?

[diogo]

I always forget that I can combine roles! I'm working on it but still no luck, I created a role "sort" and gave it permission to sort children but not to edit the page, than I went the user and added the "sort" role to it. Than I went to the parent template but I can't do much there. For the "sort" role I have the "view" checked and I can't check anything else, and it doesn't make any difference. I will play a bit with users and roles when I have some time to spend on it. I didn't do it before because I never had a real need.

[ryan]

Taking a closer look now, and apologies but I haven't had enough sleep -- the parent is responsible for the order of children. So page-edit on the parent is a pre-requisite to being able to apply page-sort there. The order of children is considered kind of like a field on the parent. If it weren't, then the user with page-sort permission would be able to go sort anything they had view access to (which I'm guessing most of us wouldn't want). Though it may be feasible that I could make page-sort accessible if the user has page-add permission on the parent.

[apeisa]

I think there are some difficulties with current way permissions are handled. I think most of the misunderstood come from the fact, that certain permissions are set directly at the template => access view and others are combined from role permissions and if "edit pages" is granted from template level. Those who have been here from 2.0 (and used permissions back then) understand well why it is so - but current situation is little bit difficult and confusing.

I think all the page creating / editing / moving etc permissions should be set on template => access view. So it would look like this:

Access tab would have these:

VIEW | EDIT | DELETE | CREATE | CLONE | ADD CHILDREN | LOCK | MOVE | SORT

And default permissions would be all the others:

page-template (changing templates)

user-admin

profile-edit

I know that there comes lot of flexibility to having permissions tied into roles, but when it comes to template permissions I think it just adds confusion. Or is there any scenario where it is good to require permissions to be set first on permissions-roles level and then added again on template-roles level? Only thing it adds is possibility to have things like "you cannot allow page-editing for these roles in this template, because that role doesn't have page-editing permission in general", which leads to confusion and restrictions like diogo has above.

I know this is something that I and Ryan have talked about million times, and now that I have built few more sites with little bit more challenging user access schema I am pretty confident this is a way forward.

[ryan]

Permissions aren't a static thing, so I'm reluctant to start adding more static columns of permissions to templates. Permissions are ultimately just pages and any number of unknown permissions can exist. I can't drop permission-to-role assignment because that's the basis of our RBAC, or any RBAC. It would be throwing out the baby with the bathwater. Connecting permissions to the templates (or pages) is just a way of saying where the user can apply a group of permissions that they have. This is an expected part of an RBAC, connecting a group of permissions with another entity for further qualification (whether a page, template or something else). That doesn't mean it's always easy to understand, and RBACs are never straightforward to understand at first glance, but they are powerful.

We've attempted to make it more straightforward by separating out a few specific permissions in the template (page-view, page-edit, page-create, page-add) rather than just giving them 1 checkbox that applies all the page-* permissions present in the user's roles (as in most RBACs). But it's a balance of figuring out how far to go with it. If you start taking it to the extreme, then the purpose and power of the RBAC gets lost. Having page-view, page-edit, page-create, page-add in the template access is actually unnecessary for us, but it does reduce the quantity of permissions and roles necessary to achieve a particular access control scenario (which I think is a good thing). However, it's ultimately a tradeoff because it's limiting the power of the RBAC just by having it work that way (like Diogo found). But I think it's a balanced tradeoff because it ultimately reduces complexity, especially for those not familiar with RBACs.

Currently, all the page-* permissions except for page-view are activated by page-edit as a kind of a parent permission. So if the user has page-edit, then any other page-* permissions they have get activated along with it. We've separated out page-create and page-add for finer control over those aspects. And we could continue separating out more like you suggested (the ones that are currently parented by page-edit). But I don't want to push further in that direction because I think it's fighting the RBAC and reaching further towards something that can't scale beyond a predefined set of permissions. Adding more columns of permissions in the template only solves it for one person's needs. Eventually WillyC will come along and want to assign page-yoda permission to a template independently of any other permissions.

I'd rather go in the opposite direction and reduce what permissions can be assigned at the template (by default), but make it definable. Imagine going to Modules > Process > ProcessTemplate > [edit module settings] and selecting from an asmSelect which permissions should be assignable at the template level -- a nice power user option? That way we aren't presenting a giant table of checkboxes for the vast majority that do not need this, but we are giving the power-user option to those that do. After all, this is the first time I've ever heard of someone wanting to give access to sort children of a page without being able to actually edit the page. So it seems like an unnecessary level of complexity for most to have to consider these rare cases every time they setup template permissions. But if we give the superuser control over what permissions deserve this "assignable at template" status, then I think that lets us veer towards simpler and more powerful at the same time.

[apeisa]

Thanks Ryan. I do agree what you say. Going to direction I suggested could lead into Drupal way to manage permissions - which is called checkbox maze.

Currently, all the page-* permissions except for page-view are activated by page-edit as a kind of a parent permission. So if the user has page-edit, then any other page-* permissions they have get activated along with it.

I think this is the pain point and not clear enough from current screen.

I'd rather go in the opposite direction and reduce what permissions can be assigned at the template (by default), but make it definable. Imagine going to Modules > Process > ProcessTemplate > [edit module settings] and selecting from an asmSelect which permissions should be assignable at the template level -- a nice power user option?

I like this thinking. Most of the time when you tick "page-edit" permission from template => access, you also tick create and add children permissions. But there are those circumstances where you need more granular permissions on templates and this would allow it.

[diogo]

Currently, all the page-* permissions except for page-view are activated by page-edit as a kind of a parent permission. So if the user has page-edit, then any other page-* permissions they have get activated along with it. We've separated out page-create and page-add for finer control over those aspects. And we could continue separating out more like you suggested (the ones that are currently parented by page-edit). But I don't want to push further in that direction because I think it's fighting the RBAC and reaching further towards something that can't scale beyond a predefined set of permissions. Adding more columns of permissions in the template only solves it for one person's needs. Eventually WillyC will come along and want to assign page-yoda permission to a template independently of any other permissions.

I mostly agree with this, but on the tree it shows for each page: | edit | view | new | move |, and you have fine grained control over the first three but not over the last one. If you see it from this prism, maybe "sort" would also have a logic place on that restriced group of template permissions.

[ryan]

I mostly agree with this, but on the tree it shows for each page: | edit | view | new | move |, and you have fine grained control over the first three but not over the last one. If you see it from this prism, maybe "sort" would also have a logic place on that restriced group of template permissions.

These also aren't static, as modules can add anything here. For instance, the Page Clone module and Nico's Page Delete module. Though I do like the idea of having that parallel.