Before we dive into the user interface for adding and maintaining various portal resources, it is best to go over the concepts Liferay uses to organize a portal.
Portals are accessed by Users.
Users can be collected into User Groups.
Users can belong to Organizations.
Organizations can be grouped into hierarchies, such as Home Office → Regional Office → Satellite Office.
Users, Groups, and Organizations can belong to Communities that have a common interest.
Within Organizations and Communities, users can belong to Teams, which are groupings of users for specific functions within a community or organization.
The simplest way to think about this is that you have users and various ways those users can be grouped together. Some of these groupings follow an administratively organized hierarchy, and other groupings may be done by the users themselves (such as different users from multiple organizations starting a community called "Dog Lovers" that has a common interest in dogs). And other groupings may be done administratively via Roles for other functions that may cut across the portal (such as a Message Board Administrators role made up of users from multiple communities and organizations, allowing those users to administer any message board in the portal).
This way of organizing portal concepts may be illustrated as shown on the next page.
In the illustration below, each arrow may be read using the words "can be a member of." So this means that Organizations can be members of Communities, Communities can be members of Roles, Users can be members of anything, and so on. Though this seems very complex, it provides a powerful mechanism for portal administrators to configure portal resources and security in a consistent and robust manner. It is important to note that the diagram illustrates only users and their collections. Permissions do not flow through all of these collections: permissions can be assigned to roles only.
Illustration 15: Liferay permissions model. Don't worry, it's not as complicated as it seems.Teams are inside individual organizations and communities, and are only available as they are created within those organizations and communities. Roles that appear inside organizations and communities are roles that are scoped just for organizations and communities. This means that though each organization and community in the portal has this role with its configured permissions, membership in this role is different for each organization and community.
Users represent physical users of the system. These are the user accounts that people use to log into the system. By default, users get their own private communities with public and private pages that they can manage themselves, and this can be turned off or locked down by administrators. But this personal space is important: it's what enables users to have their own public blog or their own private calendar, a place to store their documents, and more.
Users can be collected in multiple ways. They can be members of organization hierarchies, such as Liferay, Inc. → Security → Internet Security. They can be collected into arbitrary user groups, such as Bloggers, which could be used to set apart users who get a Blog page in their personal space from users who do not. They can be members of communities which draw together common interests. And they can have roles which define their permissions in the system, and these roles can be scoped by Portal, Organization, or Community.
User Groups are simple, arbitrary collections of users, created by administrators. They can be members of communities or roles. Permissions cannot be assigned to User Groups. Though User Groups do not have pages like some of the other collections of users (such as Communities or Organizations), they do have page templates which can be used to customize users' personal sets of pages. This will be fully described below.
There are three kinds of roles:
These are called role scopes. Roles are used to define permissions across their scopes: across the portal, across an organization, or across a community. For example, consider a role which grants access to create a Message Board category. A Portal role would grant that access across the portal, wherever there was a Message Board portlet. A Community role would grant that access only within a single community. An Organization role would grant that access only within an Organization.
Because Roles are used strictly for portal security, they also do not have pages, like Communities and Organizations.
Users, User Groups, Communities, or Organizations can be members of a role.
Organizations are hierarchical collections of Users. They are one of the two types of portal resources that can have pages. There is also a special type of Organization called a location, which can define where users are specifically located.
Organizations are handy for defining where a user belongs in a particular hierarchy. For example, if you are implementing Liferay for a large organization, it may help to define user Joe Smith via his position in the organization chart. If Joe Smith is a Sales Engineer located in the New Jersey office, working in the North East division of the Sales department, he might be a member of the following organizations:
North East Division
New Jersey Location
Now say that you have placed an Asset Publisher portlet as a static portlet on every user's home page (via a User Group page template) so that you can inform employees of various announcements via the content management system. If you tagged your content appropriately, you could ensure that Joe Smith gets any announcements that are meant for Sales, the North East Division, or the New Jersey location.
Organizations can be members of Communities.
Communities are collections of Users who have a common interest. Liferay's default pages are part of a community named for the portal, because everyone—whether they are anonymous or members of the portal—has a common interest in the default, public pages of your site. There are three types of Communities:
An Open Community (the default) allows portal users to join and leave the Community whenever they want to, using the Control Panel or a Communities portlet added to a page which they can access. A Restricted Community requires that users be added to the Community by a community administrator. Users may use the Control Panel or the Communities portlet to request membership. A Hidden community is just like a Restricted community, with the added concept that it does not show up at all in the Communities portlet or the Control Panel. Users will have to be added to a hidden community by a community administrator.
Teams are unique within a context of a Community or Organization. Teams are essentially sets of users that can be created within a community. This makes teams different from the Community and Organization Roles because teams appear only in the specific community or organization in which they are created. This is very useful if you need to create a team of users for a specific purpose within a community or organization and not for each community or organization in the portal.
Teams can also be essential for some use cases, because they can be created by Community or Organization Administrators. Community and Organization Administrators cannot create roles, so the ability to have teams empowers them to manage permissions at a level they weren't capable of previously.