Permissions play an important role in accessing and performing actions in eXo Platform. Depending on the permissions assigned by administrators, users can gain the Access and/or Edit permissions to sites, pages and various components of the sites.
In eXo Platform, permission types define what a user can do within a site, including:
Access permission enables users to access sites, pages or applications and content in the site pages. This permission can be set for multiple member groups.
Edit permission enables users to make changes on sites, pages or applications and content in the site pages. This permission is set for only one group at one time.
And, permission levels specify where the users' permission types can be applied in the site.
Site: The permission at the site level defines actions permitted on the site. Users with the access permission can view (but not edit) the site. Meanwhile, users with the edit permission at the site level can modify the site.
Page: The permission at the page level restricts users to several particular pages. Users are only able to see and/or edit pages they have been granted, depending on the permission type assigned to them.
Application: The permission at the application level defines who can access the application.
Container: An application, page, or site may be put into one or more containers. The permission at the container level restricts the Access permission to content inside it.
With these permission types and levels, administrators can effectively control who can access and which actions users can perform within the site. For this reason, you, as an administrator, need to clarify the layered architecture of a site to grant appropriate permissions to groups. The simplest way to understand is that:
A site consists of one or more pages. These pages may be put into one or more containers.
Each page normally contains content and/or application(s). These content and applications may be put into one or more containers.
If you want members under a group (platform/guests, for example) to be accessible to one application on a site page, grant the Access permission to that group at the following layers:
The application and its containers
The page and its container where the application is stored.
The page site and its containers.
In the case you only grant the Access permission to the platform/guests group at the site and page layers, this group will see the page, but not see the applications and content restricted in that page. To be clearer, see the below example.
Making guests accessible to the Register form of Intranet
Tip
To make handy for checking permissions at all levels, it is recommended you use the root account to have the highest rights.
For the Intranet site, the Register form is already featured by the Register application and put into the Register page (node)
(by selecting
→ → → next to intranet).
By default, the Register node is already linked to the Register page and this page already contains the Register application.
You can use the URL format to access pages existing on a site: http://mycompany.com:port/portal/{site_name}/{node_name}. Remember that {site_name} and {node_name} are case-sensitive.
In this scenario, log out and use the URL: http://mycompany.com:port/portal/intranet/Register. Now, as a guest, you will be redirected to the Login form, not Register form. This may be because the Access permission is not granted to the platform/guests group (or is not made public) at the Register application itself or its outer layers. To make it accessible to the platform/guests group, do as follows:
Log in as root, then use http://mycompany.com:port/portal/intranet/Register to go to the Register page.
Check the Access permission at the Register page level by clicking
→ → .
i. At the application, the Access permission is already granted to the /platform/guests group by default.
ii. At the container (by selecting Containers tab in Page Editor), the Access permission is already granted to the platform/guests group. Repeat this step for each container.
iii. At the page (by selecting at the Page Editor bottom), the Access permission is already granted to the platform/guests group.
Note
Remember to click
to make your changes affect, if any.Go to http://mycompany.com:port/portal/intranet to be at the site level, then select
→ → .
i. At the site container(s) containing the Register page, the Access permission is made public by default, meaning that all (including guests) can access at the site container.
ii. At the outermost layer of the Intranet site (by clicking at the bottom of Edit Inline Composer), the Access permission is already assigned to the platform/users group only. This is the reason why guests cannot access the Register form. So, in the Access Permission Settings tab, you need to select → → in the group pane, and * in the membership pane. Alternatively, tick the Make it public (everyone can access) checkbox.
Note
Remember to click
to make your changes affect, if any.Log out, then try using the http://mycompany.com:port/portal/intranet/Register link. Now, as a guest, you still can view the Register form, not the Login form.
Optionally, if you want guests to be redirected to the Register form when they only enter http://mycompany.com:port/portal/intranet, simply move gradually the Register node to the top in the Navigation Management (by right-clicking Register and selecting Move Up - you need to repeat this step until the Register node is at the top).
Log out, then use the link: http://mycompany.com:port/portal/intranet. Now, you will be redirected to the Register form without entering the exact URL of the Register page.
Note
In this section, some examples and screenshots use default groups and memberships that are ready-made by configuration. To create groups and memberships as you want, see Managing your organization.
Do not misunderstand that labels of predefined membership types, such as "manager" or "publisher", represent their permissions. This means, those labels do not define any permissions. If you create a page, you are the person who decides if a "manager" has access to your page or not.
Permissions in this section are divided into: