Class ResourcePermissionImpl

Object
com.liferay.portal.kernel.model.impl.BaseModelImpl<com.liferay.portal.kernel.model.ResourcePermission>
All Implemented Interfaces:
com.liferay.portal.kernel.model.BaseModel<com.liferay.portal.kernel.model.ResourcePermission>, com.liferay.portal.kernel.model.change.tracking.CTModel<com.liferay.portal.kernel.model.ResourcePermission>, com.liferay.portal.kernel.model.ClassedModel, com.liferay.portal.kernel.model.MVCCModel, com.liferay.portal.kernel.model.PersistedModel, com.liferay.portal.kernel.model.ResourcePermission, com.liferay.portal.kernel.model.ResourcePermissionModel, com.liferay.portal.kernel.model.ShardedModel, Serializable, Cloneable, Comparable<com.liferay.portal.kernel.model.ResourcePermission>

public class ResourcePermissionImpl extends ResourcePermissionBaseImpl
Stores the permissions assigned to roles under permissions version 6. A resource permission gives a role the ability to perform a set of actions on certain resources.

The type of resource a permission applies to is specified by the name attribute. It will either be the numeric ID of a portlet, or the fully qualified class name of a model (such as a layout or document library folder).

These permissions can apply in one of four scopes: company, group, group-template, or individual. The scope of a permission determines how broadly it applies to resources in the portal. Company scope is the broadest, and grants a user with the role permissions for every resource of the type within the company. Likewise, group scope gives users with the role permissions for every resource within the specified group, and individual scope only applies to a single resource of the type. Group-template scope is similar to group scope, except that it does not automatically apply to a specific group. A user must be a member of a group (generally either a site or an organization), and they must have been given the role within that group before they are granted its permissions.

Note: Lacking permission to perform an action on a resource at one scope does not necessarily mean that a role does not have permission to perform that action. For instance, a message boards moderator role will not have individual scope permissions to edit every post, but it will have edit permissions at the group or company level, which is sufficient. Every scope must be checked.

The scope of the resource permission also determines the meaning of the primKey attribute. Its different uses are listed below:

  • Company scope - primKey is the primary key of the company
  • Group scope - primKey is the primary key of the group the permission applies within
  • Group-template scope - primKey is always 0
  • Individual scope - If the permission applies to a model instance, primkey will be the primary key of the instance. If the permission is for a portlet, primKey will contain the primary key of the layout containing the portlet, followed by "_LAYOUT_" and the portlet ID. The instance ID will also be present for instanceable portlets, preceded by "_INSTANCE_".

The actionIds attribute stores the bitwise IDs of all the actions allowed by this permission.

Author:
Brian Wing Shun Chan
See Also:
  • Constructor Details

    • ResourcePermissionImpl

      public ResourcePermissionImpl()
  • Method Details

    • addResourceAction

      public void addResourceAction(String actionId) throws com.liferay.portal.kernel.exception.PortalException
      Throws:
      com.liferay.portal.kernel.exception.PortalException
    • hasAction

      public boolean hasAction(com.liferay.portal.kernel.model.ResourceAction resourceAction)
    • hasActionId

      public boolean hasActionId(String actionId)
    • removeResourceAction

      public void removeResourceAction(String actionId) throws com.liferay.portal.kernel.exception.PortalException
      Throws:
      com.liferay.portal.kernel.exception.PortalException