If a role were to win a Grammy or an Oscar or some other ego-feeding popularity contest, it better remember to thank all its permissions groupies during the acceptance speech, because they’re the ones doing the real work. The role is just the pretty face, so to speak.

Roles collect permissions that define a particular function within Liferay Portal, according to a particular scope. Roles collect permissions, and users are assigned to roles, either directly or through their association with a User Group, an Organization, or a Site.

Take a Message Board Administrator role, for example. A role with that name is likely to have permissions relevant to the specific Message Board portlets delegated to it. Users with this role inherit the permissions collected underneath the umbrella of the role.

Roles are managed through the Control Panel.


Managing Roles in Liferay

Manage Liferay’s roles in the Control Panel (Control PanelUsersRoles). There you’ll find an application for creating roles, granting them permissions, and assigning users to them. Roles can be scoped by portal, site, or organization.

Figure 1: The Roles application lets you add and manage roles for the global (Regular), Site, or Organization scope.

To create a role, click the scope you want a role for and then click the Add (icon-add.png) button. Enter a name, title, and description for the role. The name field is required but the title and description are optional. If you enter a name and a title, the title is displayed in the list of roles on the Roles page of the Control Panel. If you do not enter a title, the name is displayed. When you finish, click Save.

Note: In addition to regular roles, site roles, and organization roles, there are also teams. Teams can be created by site administrators within a specific site. The permissions granted to a team are defined and applied only within the team’s site. The permissions defined by regular, site, and organization roles, by contrast, are defined at the portal level, although they are applied to different scopes. The differences between the four types of roles can be described as follows:

* Regular role: Permissions are defined at the //portal// level and are applied at the //portal// level.

* Site role: Permissions are defined at the //portal// level and are applied to one //specific site//.

* Organization role: Permissions are defined at the //portal// level and are applied to one //specific organization//.

* Team: Permissions are defined within a //specific site// and are assigned within that //specific site//.

Read here For more information about teams.

After you save, your role is added to the existing list of roles. To see what functions you can perform on your new role, click the Actions button.

Edit: lets you change the name, title or description of the role.

Permissions: allows you to define which users, user groups or roles have permissions to edit the role.

Define Permissions: defines the permissions the role contains.

Delete: permanently removes a role from the portal.

Once you have a role you want to configure, the first step is often to define its permissions.

Defining Role Permissions

Roles collect permissions, so when a user is given a role, they receive all the permissions defined by the role.


Figure 2: When defining permissions on a role, the Summary view provides a list of permissions that have already been defined for the role. The area on the left side of the screen lets you drill down through various categories of portal permissions.

To add permissions to a role, click on the Actions (icon-actions.png) button for a regular role and select Define Permissions. Find the permissions you want to add by navigating the categories of permissions on the left side of the screen and click on a specific category (such as Site AdministrationNavigationSite Pages). Select any permissions that you’d like to add the role, then click Save.

Note: The Roles application in the Control Panel is not the only place where permissions are configured. You can configure a role’s permissions for a particular application instance from its Options (icon-options.png) menu. However, permissions granted or removed in the Control Panel override those made at the more granular level.

There are three basic categories of permissions: Control Panel, Site Administration, and User. By default, any Liferay user can manage their user account via the permissions belonging to the User category. Site Administrators can access the site administration tools belonging to the Site Administration category. Portal Administrators can access the entire Control Panel. For custom roles, you can mix and match permissions from as many categories as you like.

The permissions in the Site Administration → Applications categories govern the content that can be created by core portlets such as the Wiki and Message Boards. If you pick one of the portlets from this list, you’ll get options for defining permissions on its content. For example, if you pick Message Boards, you’ll see permissions for creating categories and threads or deleting and moving topics.

Site application permissions affect the application as a whole. Using the Message Boards as an example, an application permission might define who can add the Message Boards portlet to a page.

The Control Panel permissions affect how the Control Panel appears to the user in the Control Panel. The Control Panel appears differently to different users, depending on their permissions. Some Control Panel portlets have a Configuration button and you can define who gets to see that. You can also fine-tune who gets to see various applications in the Control Panel.

If you want to change the scope of permission, click the Change link next to the gear icon next to the permission and then choose a new scope. After you click Save, you’ll see a list of all permissions currently granted to the role. From the Summary view, you can add more permissions or go back to the Role Application default view by clicking on the Back (icon-back.png) icon.


Figure 3: You can fine-tune which actions are defined for a role within a specific application like the Message Boards.

Sometimes you might find that a certain permission grants more or less access than what you expected–always test your permissions configurations!

Suppose you need to create a role called User Group Manager. You’d like to define the permissions for the User Group Manager role so that users assigned to this role can add users to or remove users from any user group. To do this, you can take the following steps:

  1. Go to the Control Panel and then click on UsersRoles.
  2. On the Regular Roles screen, click Add (icon-add.png).
  3. After naming your role and entering a title, click Save.
  4. Click on Actions (icon-actions.png) → Define Permissions and drill down in the menu on the left to Control PanelUsersUser Groups.
    • Under the General Permissions heading, flag Access in Control Panel and View. This lets user group managers access the User Groups Control Panel portlet and view existing user groups.
    • Since you’d like user group managers to be able to view user groups and assign members to them, you’d also check the Assign Members and View permissions under the Resource PermissionsUser Group heading.
  5. Click Save.


Figure 4: Make sure to test the permissions you grant to custom roles.

Once you create the role, assign it to its intended users. To assign roles to Users, Sites, Organizations, and User Groups, click on the role, then click on the Add button (icon-add.png). Choose the users and/or groups you want to assigned to the role. If assigning a group, note that all users assigned to that group will inherit the role as well.

You might expect that the role has all the permissions necessary for adding users to user groups. After all, user group managers can view user groups, assign members, and access User Groups in the Control Panel. However, we’re forgetting an important permission: the User Group Manager role can’t view users! This means that if they click Assign Members for a user group and click on the Available tab, they’ll see an empty list.

If you create a role with permission to access something in the Control Panel, keep in mind that the View Control Panel Menu permission will be automatically granted. Consider why this is necessary with an example.


Figure 5: Users assigned to the User Group Manager role can’t find any users to add!

To fix this, define the missing permission on the role by drilling down to the Control PanelUsersUsers and Organizations category and flag the View permission under the Resource PermissionsUser heading. Once you’ve saved your permissions configuration, users who’ve been assigned to the User Group Manager role will be able to browse the portal’s entire list of users when assigning users to a user group.

Roles are very powerful and allow portal administrators to define various permissions in whatever combinations they like. This gives you as much flexibility as possible to build the site you have designed.

Delete a Role

1- Go to Roles

2- Select the role you want to delete

3- Deletethe role

Permission for Delegating Social Activities Configuration

There’s a permission that allows site administrators to delegate responsibility for configuring social activities to other users. To dd this permission to a role, click Actions next to the desired role and select Define Permissions. Find the Site AdministrationConfigurationSocial Activity permissions category. Flag all of the permissions and then click Save:

  • Access in Site Administration
  • Configuration
  • Permissions
  • Preferences
  • View

Once these permissions are assigned, assignees can manage the site’s Social Activities.

Deleting Asset Containers

A Web Content Folder contains Web Content articles. The Web Content Folder is an asset container, and the Web Content Article is an asset. It’s possible to give a role permission to delete an asset container without giving the role permission to delete individual assets. In that case, beware: if a role assignee deletes an asset container with individual assets in it, the individual assets themselves will be deleted as well.

Besides Web Content Folders, examples of asset containers include Bookmarks Folders, Message Boards Categories, Wiki Nodes, and Documents and Media Folders.

You might not need to create a role for certain functionality. Liferay provides many pre-configured roles for your convenience.

Default Roles

In the Roles Application, you’ll see a list of all the roles in Liferay, by scope. These are some of the pre-configured roles:

  • Guest: The Guest role is assigned to unauthenticated users and grants the lowest-level permissions within the portal.
  • User: The User role is assigned to authenticated users and grants basic permissions within the portal (mostly Add to Page permissions for applications).
  • Data Specialist: The User role is assigned to authenticated users and grants basic permissions within the portal. This user can access to Explore, Community, Orchestration sections. He can't access to Eclipse che, Jupyter, Gitlab
  • Portal content reviewer is the moderator role. He can create content in the platform, delete a thread on the forum, etc...
  • Power User: The Power User role grants more permissions than the User role. It’s designed to be an extension point for distinguishing regular users from more privileged users. For example, you can set up your portal so that only Power Users have personal sites.
  • Administrator: The administrator role grants the ability to manage the entire portal, including global portal settings and individual sites, organizations, and users.

Setting default Roles

By default, after registration, the user has automatically the role of Data Specialist.

To change this default role by another one please, follow his steps :

Average (0 Votes)