I don't believe that answers the question, as I have the same issue. I, too, have a HR role and need to restrict people in that group to only being allowed to edit a particular page. The problem as stated is, when I break permissions for that page and add the role to that page to edit, there is no Pages tab at the top, NOR is there an option to edit the page when browsing the front-end.
It seems that the expected behavior is from the perspective of the HR user who is logged in: if I am in this role and have permissions for at least one page to edit, I should have the option to navigate to that page.
It seems the only option to get this Pages tab to show, is add the HR role to "Permissions for all pages", but explicitly deny access to every single page. Obviously this is a nightmare.
So, to accomplish this, what is the solution? Thanks.
EDIT: it also seems that even if I just have editable permissions for the HR role on a specific page, that user STILL cannot access the page (it throws a 500 error). Say, the /careers page is the page in question. If logged in, the user cannot access /careers/action/edit in the back-end, even though this HR role has edit permissions for that page.
I'm having horrible flashbacks from a year ago when we needed to do the same thing.
Logic dictates that when you give someone explicit permissions to edit a page, then when they log into the backend...they see the pages node and that page.
I don't even think telerik disagrees with this, but they just haven't fixed it (or won't fix it, no idea). Sit 100 people in a room to try to do this exact task, I guarantee you 100 will walk out frustrated without solving it.
Okay so here's what we did. The default "PageEditor" role is a dummy role now...users in that role only get to see the backend "Pages" section, but they have no further rights to DO anything. Then we give those users rights to THEIR pages.
So that seems to work for us, however there seems to now be a bug in 5026 where the styling doesn't let the user see which pages they can edit. I remember it USED to grey out the links they couldn't click in the treeview...but now all the links are the same color...not all are clickable though, like the cursor doesn't change to a pointer on the disabled ones...but good luck knowing which pages you can change.
I'm trying what you mentioned, but I'm not sure what the "PageEditor" role is. I have "editors".
I actually tried one thing, where I set "Use in-line editing" to be allowed for this HR role. While it doesn't get the Pages menu in the back-end, it does now allow just that particular page to be edited via the front-end.
This may work for our purposes.
Sorry my bad you're right...we instead split editor up into
...for more control
You're saying to go to "Permissions for all pages" and add this HR role as DENY under "Edit page content", then for the pages that I DO want them to edit, break the inheritance by removing the role?
If so, that doesn't work and the Pages tab isn't visible.
If I'm reading your response incorrectly, could you please post a screencast of adding a new role (call it "HR" or something), follow your suggestion, and hopefully show the Pages tab in the back-end?
So far, the only thing that works for me is keeping the user on the front-end and enabling page edit tools. All I did here was ADD the new HR role to just this page. However, they still don't have access to the Pages tab (this may or may not be an issue for others). In my case, it's a work-around.
Yes, please make sure this feedback gets to your UX team. Can't believe something as simple as this hasn't come up (and get fixed) after 6 iterations of the software. Thanks.
Could this link from Nov 2012 be releated
If this is the case then I did choose the right title back then. If not sorry.
It turned out that there is a new setting in
Administration -> Settings -> Advanced -> Pages -> Sitemap filters ->Admin ->Parameters -> IsFrontendPageManagementFilteringEnabled
Hope to hear from you if this setting did help you.