Permission for single page

I created a sub page and set the permissions so that the "HR Admin" role can edit that page. The problem is that when the user that is in that role logs in to the backoffice, there is only a "Dashboard" tab, but they can't see any pages. What am I doing wrong?

Thanks

Hi,

If you want to change a permissions for a current page for example: Test you need to:
1. Go to Actions -> Permissions
2. Break inheritance
3. Change permissions

If you want to change permissions for all pages, you need to:
1. Go to Page section
2. Select Permissions for all pages
3. Change permissions

You should also go to Administration -> Permissions and select by Role or User select the User/Role and change its/theirs permissions in the Page section.

I would also suggest you to review our Sitefinity documentation:

http://www.sitefinity.com/documentation/documentationarticles/installation-and-administration-guide/users-roles-and-permissions/managing-permissions


Regards,
Stefani Tacheva
Telerik

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.  

 Nope

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.

Steve

Thanks, Steve. 

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

DocumentEditor
PageEditor
ImageEditor

...for more control

Hi,

Thank you for your feedback. We are aware of this behavior and we are going to create an article about how permissions should be configured including some detailed information.

Regarding the problem that you are having what we could suggest you is to Deny Edit permissions for pages for all users on global or parent level and then break inheritance per page level and remove this deny permissions. Then you there will be no need to go through all pages and deny permissions. You will go through only these page which you want to be edit by your users.

If you have 50 pages and you globally change the permissions to Deny some roles or users and then you go to one page, which a role or user should be able to edit, break the inheritance and remove this Deny permissions, then the role or user will be able to access only this page and will not be able to access the other page.

I will make sure that your feedback is forward to our UX Team.

Regards,
Stefani Tacheva
Telerik

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.

Hi,

Please review the configurations we have made in the backend for the custom role:

http://screencast.com/t/DXl5II4Uu
http://screencast.com/t/FxFZ113a

And the behavior we are observing:

screencast.com/.../dkRoQsHIjTq

The user in the newly created custom role is unable to edit all pages that inherit from their parent (that inherit from global permissions), but it is able to edit the page where the permission inheritance has been broken and the deny permissions have been removed.

Note that this behavior could be observed in Sitefinity 6.3.5000.

Regards,
Stefani Tacheva
Telerik

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.

www.sitefinity.com/.../grant-page-acces-to-role-in-backen!-don't-waste-an-hours-

 It turned out that there is a new setting in 

Administration -> Settings -> Advanced -> Pages -> Sitemap filters ->Admin ->Parameters -> IsFrontendPageManagementFilteringEnabled

Markus

Hi,

This property is set to true by default. The default behavior is that if you generally cannot manipulate pages you don't need to view pages in the backend. However you can easily change this by navigation to Administration -> Settings -> Advanced -> Pages -> Sitemap filters -> Admin -> Parameters -> IsFrontendPageManagementFilteringEnabled, setting the Value to "false" and clicking Save.

Regards,
Stefani Tacheva
Telerik

@Doug

 Hope to hear from you if this setting did help you.

 Markus