Page permissions allow you to control who can access sections or pages of your site. For example, you can restrict who can create or edit pages or restrict viewing access to the live site.
Page permissions can get complex, so we've created the list of FAQs below; please browse our list of questions and answers and contact us if you're still having trouble.
If you need help setting your permissions up, check out this article about how to use page permissions.
What is the difference between child page and current page permissions?
You can use the following options when setting page permissions:
-
Set Child Page Permission: control access for every child page below the selected page. This will apply to every level of that section in your site tree. In the image below, child permissions applied to Our Services will apply through every level, including the fourth-level page Animal registration.
- Set Current Page Permission: control who can access the current selected page. In the image above, the current page permissions set for Animals will only apply to that page.
What do each of the permissions tabs do?
There are six tabs for both child and current page permissions:
- Access: control which users and roles can create, edit, archive, or delete pages or sections. For example, you can limit your library section so that only users with a library content role can work within those pages.
- View: control which users and roles can view the live pages or sections of your site. This option is best used with Intranets to limit viewing access to specific departments.
- Content Types: control which content types can be created under a branch of your site. For example, you can restrict your services section to OC Service pages only or use current page permissions to ensure that a page can't be changed to any other content type.
- Approval Workflows: assign an approval workflow to the section or page of your site. Please note that workflows work best when applied to content types rather than your site tree.
- Workflow Update: assign an update workflow to the section or page of your site. Please note that workflows work best when applied to content types rather than your site tree.
- Workflow Delete: assign a deletion workflow to the section or page of your site. Please note that workflows work best when applied to content types rather than your site tree.
What do the buttons do?
- Clear Permissions: clear permissions from this current page or the direct child pages.
- Clear all child page permissions: clear permissions from the root page, direct child pages, and all descendent child pages from the root page. This is only available for child page permissions.
- Close Window: close the page permissions window when you're finished assigning permissions.
- View Full Page Access: see the complete list of users and roles who can access the page or section.
- Apply Changes: apply the permissions you set. If you're using child page permissions, this will also clear and reapply the permissions you chose to all child pages and descendants within that section.
- Merge all child page permissions: apply permissions to the child pages, while retaining any permissions already set within that section. This is only available for child page permissions.
Who can control page permissions?
OC Site Managers can apply page permissions to the sites they can access, while OC System Administrators can apply page permissions to all sites.
How does this relate to role permissions?
When you assign page permissions, you deny or allow access within the site tree to specific roles or users. Roles restrict who can access areas of the admin or perform certain content author tasks.
It might be helpful to create specific roles for users in conjunction with setting page permissions. For example, you could create a role that is specific to the needs of the library content authors. You could then set this role as the only user who can create or edit pages under the library section of your site.
Can I use page permissions to control who can view my live site?
Yes, you can use the View tab to deny or allow specific roles' and users' viewing access to pages and sections on your live site. A few things to consider:
- Use this option only with Intranets or password-protected subsites; using this tab on your public sites will restrict the public from viewing your content.
- If you use this option to restrict access to sections of your Intranet (only the HR department can view a group of HR policies, for example), you may want to create a custom role for all HR staff members. This will allow you to Deny all users except those with the custom role, and you can give or take that role to staff members as necessary.
- To restrict viewing access to a complete branch of your site tree, you must apply current and child page permissions to the top-level parent page of that section.
Why are the page permissions applying to all child pages, but not the parent page?
When applying permissions to an entire branch of your site tree, you must place child page permissions and current page permissions on the top-level parent page of that section.
What does it mean to "inherit" permissions?
When you apply child page permissions to a parent page, each page below will also have the permissions you set. When you set child or current page permissions to a page with inherited permissions, the Permission status will show you if the page has any inherited permissions.
However, you can still apply different current or child page permissions to pages with inherited permissions.
What happens if you apply different child or current page permissions within a section that already has child page permissions applied?
There are a few scenarios here, and we'll use the pages in this image to go through them.
- Once you apply child page permissions to Our Services, those permissions will apply to each child page on each level below it.
- You can then apply child page permissions to Works & Projects, and all pages below it will inherit the permissions set on Works & Projects, instead of those from Our Services. The pages Animals, Lost animals, and Animal registration will still inherit the permissions applied to Our Services.
- You could also set current page permissions on Works & Projects, and that page will no longer inherit permissions from Our Services.
- If you then go back and reapply different child page permissions on Our Services, selecting Apply Permissions will override the page permissions set on Works & Projects and its child pages. So Works & Projects and its child pages will once again inherit permissions from Our Services.
- Alternatively, selecting Merge all child page permissions would retain the permissions set on Works & Projects, while applying the new permissions to Animals and its child pages.
How do I remove all page permissions from my site tree?
To continue the above example, you can Clear all child page permissions from Our Services to ensure no page permissions remain in that section. Please note that while this has cleared all page permissions below this page, you must still individually remove any current page permissions set for Our Services.
You must do this for every top-level parent page in your site tree to ensure no child page permissions remain.
I used the Clear Permissions option on the parent page, why are there child pages I can't access?
You may have pages with current page permissions as well, and you'll need to clear these individually.
Additionally, you will need to select Clear all child page permissions to remove all permissions from that branch of the site tree.
How can I check which users or roles have permission to access a page?
The best way to find what permissions are in place is to go into the permissions for the page or section and check the Permission status to find where the permission is coming from or select View Full Page Access to see the complete list of users and roles with access.
What can I do to minimize complications with page permissions?
We have a few tips to help you manage your page permissions:
- Document everything - internal documentation can help you keep track of which pages have which permissions. This will help if the staff member who set the permissions leaves your organization.
- Use roles rather than users to deny or allow access. This helps when people leave your organization, as you can still apply the role to new users and retain the permission. You won't have to keep editing permissions to deny or allow specific users. Using roles also allows you to create custom roles for more granular control.
- Try not to apply page permissions in a section that already has child page permissions set. It can be confusing trying to work out where a permission is coming from, and you may inadvertently remove previously set permissions if you need to edit the parent page.
- Similarly, it's generally better to clear and reapply permissions rather than edit them. This way, you can be sure exactly what permissions are applied to that section.