A resource is a generic term for any object represented in the portal. Examples of resources include portlets (e.g., Message Boards, Calendar, Document Library, etc.), Java classes (e.g., Message Board Topics, Calendar Event, Document Library Folder, etc.), and files (e.g., documents, images, applications, etc.). Resources can have one of three types of scope – enterprise, community, or individual. The diagram below shows how these types are related.

Essentially, an enterprise is the umbrella grouping for all objects within the portal. A resource that has enterprise scope applies to all objects of that type in the company. For example, a Message Board Category resource with enterprise scope encompasses every topic across all communities and all message boards within the enterprise. An enterprise can contain any number of communities. A resource that has community scope only applies to the objects within a particular community. For example, assume that the “Developer" community has several message boards. A Message Board Category resource with “Developer" community scope would encompass all category within the “Developer" message boards. Each community can contain any number of objects. A resource that has individual scope only applies to a single object. For example, assume that the “Developer" community has a message board that contains the topic “Java Issues." A Message Board Category resource with individual scope would have a one-to-one correlation with the “Java Issues" topic.

A permission is defined as an action acting on a resource. The table below gives some example permissions related to message board topics.

Enterprise and community scoped permissions can only be assigned to entities (e.g., users, communities, organizations, and locations) via roles. See section 2.3 for more details. Individual scoped permissions can be assigned to a user, community, organization, location, or guest. If a permission is assigned to a community, organization, location, or guest, then all users that are members of that entity receive that permission.

In general, permissions are additive. Therefore, a user could receive all three of the permissions in the table above even though they are all of different scope. Consider a situation where a view “Java Issues” permission of individual scope was assigned directly to a user and a view Message Board Category permission of enterprise scope was assigned to the same user through a role (see section 2.3 for more information on roles). Because permissions are additive, the user could receive the view permission for the “Java Issues” category from either the individual or enterprise scope. However, permissions are always checked in the following order:

Therefore, as soon as the system finds the view permission of individual scope, it stops checking and gives the user permission to view. However, also consider the case where the individual scope permission is removed from the user. Now when the system checks, it will not find an individual scope or community scope permission, but it will find the enterprise scope permission. For an administrator, this situation can often lead to a great deal of confusion – a permission is removed from one entity, but the permission is still derived from another entity. As a rule of thumb, if an administrator ever removes a permission from an entity, yet user(s) still has the permission, the administrator should look for derived permissions in the system.

A role is a collection of permissions. As such, a role serves no purpose unless permissions are assigned to it. An example role might be a “Message Board Administrator." The role might be assigned permissions to View, Update, and Delete Message Board category resources that have company scope. Ultimately, a user assigned the “Message Board Administrator" role would be able to view, update, and delete any topic for any message board in the company. Roles can be assigned to a user, community, organization, or location. If a role is assigned to a community, organization, or location, then all users that are members of that entity receive the role.

A user is an individual who performs tasks using the portal. Depending on what permissions and roles that have been assigned, the user either has permission or does not have permission to perform certain tasks. Before logging in to the portal, a user is considered a guest. Guests have their own set of default permissions for objects in the portal, but even these can be customized by administrators. After logging in to the portal, a user is considered a registered user. Registered users can receive permissions in the following ways:

Organizations and locations represent a corporate hierarchy. An organization represents a parent corporation. An example would be Liferay USA. A location represents a child corporation of an organization, often times distinguished by its geographic location. Organizations can have any number of locations. Example locations of the Liferay USA organization might be Liferay Chicago, Liferay San Francisco, and Liferay Los Angeles. A user can only belong to a single organization and location.

Both roles and individual permissions can be assigned to organizations and locations. By default, locations inherit permissions from their parent organization. Going back to the example above, if the “Message Board Administrator" role is assigned to the Liferay USA organization, then all members of the Liferay Chicago, Liferay San Francisco, and Liferay Los Angeles locations would inherit the permissions associated with the role.

A community is a grouping of users by interest or skill set. For example, a “Pet Lovers" community would consist of users who have an interest in their pets, while a “Tech Support" community would consist of users who have the skills to provide technical support to an organization. A user can belong to any number of communities. NOTE: In previous versions of Liferay, communities were called groups. As far as permissions are concerned, communities are not specific to any organization or location. Both roles and individual permissions can be assigned to communities.

A user group is a grouping of users. Unlike organizations, locations, and communities, user groups have no context associated with them. They are purely a convenience grouping that aids administrators in assigning permissions and roles to a group of users instead of individual users or assigning a group of users to a community. A user can belong to any number of user groups. Both roles and individual permissions can be assigned to user groups, and every user that belongs to that user group will receive the role or permission.