1.1
Copyright © 2000, 2007 Liferay Inc.
| Revision History | |
|---|---|
| Revision 1.0 | January 8th, 2007 |
| Revision 1.1 | February 19th, 2007 |
|
Added information about using the workflow portlet | |
Table of Contents
List of Tables
Intended audience. This document is intended for users of the portal who have administration priviledges for the portal or for a given community. It covers administration of users, permissions, and websites.
Liferay version. This guide has been written for Liferay 4. Some details might be different for previous versions. Do not expect it to be accurate for older versions. It is assumed that Liferay has been installed and accessible through the web interface.
Related documents. If this is not what you are looking for consider the following related documents:
Liferay Portal 4 - Installation Guide
Liferay Portal 4 - Customization Guide
More information and support. If you are looking for help for a specific issue we invite you to use our community forums: http://www.liferay.com/web/guest/devzone/forums to ask your questions. We also offer professional support services (support@liferay.com) where your company will be assigned a Liferay developer ensuring your questions are answered promptly so that your project is never compromised. Purchased support always gets first priority. This business model allows us to build a company that can contribute a great portal to the open source community. If your company uses Liferay, please consider purchasing support. Liferay has an extremely liberal license model (MIT, very similar to Apache and BSD), which means you can rebundle Liferay, rename it, and sell it under your name. We believe free means you can do whatever you want with it.
Table of Contents
Liferay portal may be accessed using a browser using a regular connection (HTTP) or a secured connection (HTTPS). If you are using a default bundle installation in your local computer you can access it through the URL http://localhost:8080. Otherwise, you will have to contact your administrator to ask for the initial URL.
The home page in a default installation replicates the public Liferay website. There is a link in the upper right corner that takes the user to the login page. If it is not available in your installation you can go directly to the login page by using this URL: http://your-host-name.com/c/portal/login.
Once you are in the login page you will be asked for the following information:
The default installation is configured to login by email address. It comes with a preconfigured administrator account whose address is test@liferay.com. If you are not using the default installation you should ask the administrator which authentication system the portal using (login name or email address) and the information of an account that you can use.
The password of the preconfigured administrator account is test.
Table of Contents
Registered users of Liferay Portal who have the appropriate permissions (given with the Power User role) have a personal area, also known as the user desktop or the user private pages. The personal area is organized in a set of pages that can be organized in a hierarchy. The following sections explain how a user can customize it.
Before continuing this section we recommend that you login into the system as an administrator and go to your personal area.
You can add additional portlets to your page by clicking on the Add Content link. This will bring up a Content Panel on your screen. Choose a portlet from the menu and add it to your page. If the Enterprise Admin portlet is not on your page, add it now. You will see that the portlet has been added to the bottom of your page. To change the portlet placement, click on the title bar of the portlet and drag it to where you like. You can also change the template for your page with the Layout button. This will allow you to arrange your portlets in one, two, or three columns as well as designate the width of the columns. Try to experiment with adding and arranging all the portlets that you would like on this page. There are quite a few portlets that come bundled with Liferay Portal so be sure to review them alls.
At this point you have all the portlets you want on your page. You can now change the look and feel of your portal. Liferay Portal comes pre-bundled with different themes that you can apply to your page. The administrator of your portal may have configured additional theme options.
To change the theme refer to the following instructions:
Click on the Page Settings link at the top of your page.
Select the page you would like to theme on the left hand side. Note that by default all children pages will inherit the theme from the parent.
Now select the Look and Feel tab for that page.
You will see a number of bundled themes that are available with Liferay Portal. Choose your theme and color scheme. You can experiment with it as much as you like until you find a theme that pleases you.
![[Note]](images/note.png) | Note |
|---|---|
Although Liferay comes with many bundled themes, there are also a vast number of themes contributed to Liferay Portal from the community. You can view these on our website or develop your own custom theme for your company or application. Please read the Liferay Portal 4 - Theme Development guide for more information. |
Table of Contents
We will begin with an introduction to some new functionality in Liferay 4. This chapter will give an in depth tutorial on the Enterprise Admin, Organization Admin, and Location Admin portlets. Step-by-step instructions and screen shots are provided to guide users through various administration functions which are new to portal.
This document on user administration portlets begins by providing an overview of entities involved in the administration portlets. This will be followed by instructions on using each of the three administration portlets.
Liferay Portal provides three administration portlets: Enterprise Admin, Organization Admin, and Location Admin. The three portlets provide different scopes of administration.
As illustrated by the diagram, the Enterprise Admin Portlet has the highest level of administrative functions. It has access to all organizations, locations, and users. The Organization Admin Portlet can access its own information and information for any locations and users that belong to it. The Location Admin Portlet can access its own information and any users that belong to it. This chapter will only address user administration functions contained within the various administration portlets. See the Security and Permissions chapter for instructions on assigning permissions to existing portlets for individual organizations, locations, and users.
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.
A user group is a grouping of users. Unlike organizations and locations, 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.
Enterprise Administration has the highest level of administrative functions. It has access to all organizations, locations, and users.
Organizations are at the top of the group hierarchy and allows the configuration of permissions to a broad number of users in the system.
Click on the Organizations tab in the Enterprise Admin Portlet to display the Organizations screen.
A listing of organizations appears on the bottom of the Organizations Screen. Click on an organization you want to view. A screen will appear showing the organization's information.
Click on the Organizations tab in the Enterprise Admin Portlet.
Type organization information in the input fields and select from the menu options.
Click Search.
Click on the Organizations tab in the Enterprise Admin Portlet.
Click Add.
Enter organization’s information in the Name input field.
Select from the Country, Status, and Region menus.
Click Save.
To add additional organizations, repeat steps 1-5.
Locations can give you broad permissioning and grouping within an organization.
You can view a list of all locations or you can view a list of locations that belong to a specific organization.
Click on the Locations tab in the Enterprise Admin Portlet.
A listing of locations appears on the bottom of the Locations Screen. Click on a location you want to view.
To search for locations, click on the Locations tab in the Enterprise Admin Portlet.
Type Location information in the input field and select from the menu options.
Click Search.
Click on the Locations tab in the Enterprise Admin Portlet.
Click Add.
Enter location information in Name input field.
Select from the Country, Organization, Status, and Region menus.
Click Save.
To add additional locations, repeat steps 1-5.
| Note |
|---|---|
You can also add organizations through the Organizations screen. |
To edit location information, click on the Locations tab in the Enterprise Admin Portlet.
Locate the location you want to edit. Click the Edit icon (
) on the right of the location.
Type changes in the Name input field. Select from the Country, Organization, Region, and Status menu to make changes.
Click Save.
You can view active and deactivated users.
Click on the Users tab in the Enterprise Admin Portlet.
A listing of users appears on the bottom of the Users Screen. Click on a user you want to view. To see a list of additional users, click on the page numbers.
To view deactivated users, click on the Active menu from the Users Screen, and select No.
Click Search to display a listing of deactivated users.
Repeat step 2.
Click on the Organizations tab.
Click the View User
icon (
) located to the right of an
organization.
Click on a user to view.
To search for a user, click on the Users tab in the Enterprise Admin Portlet.
Type user name in the input fields and select from the menus. To search for an active user, select Yes from the Active menu. To search for a deactivated user, select No.
Click Search.
To add a user, click on the Users tab in the Enterprise Admin Portlet.
Click Add.
Enter user’s information in the input field and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
You can also add users through the Location Screen:
Click on the Locations tab in the Enterprise Admin Portlet.
Click on the Add User
icon ( 
) located to the right of the location
you want to add a user to.
Enter user’s information in the input fields and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4
You can also add users through the Organization Screen:
Click on the Organizations tab in the Enterprise Admin Portlet.
Click on the Add User
icon () located to the right of the
organization you want to add a user to.
Enter user’s information in the input field and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
To edit user information, click on the Users tab in the Enterprise Admin Portlet.
Click on the user you want to edit. A screen will appear displaying the user's innormation.
Type changes in the First Name, Middle Name, Last Name, Email, and Job Title input fields. Select from the Prefix, Suffix, Birthday, Gender, Location menus to make changes.
Click Save.
To deactivate a user, click on the Users tab in the Enterprise Admin Portlet.
Click on the box located next to the user you want to deactivate.
Click Deactivate.
You can also deactivate a user by clicking the Deactivate icon (
) next to a user.
To deactivate all users listed on a page, click the box located next to the Name column. Click Deactivate.
A screen will appear asking if you want to deactivate the selected users. Click OK to delete. Click Cancel if you do not want to deactivate the selected users.
To restore deactivated users, click on the Users tab in the Enterprise Admin Portlet.
Click on the Active menu, and select No.
Click Search to display a listing of deactivated users.
Click on the box located next to the user you want to reactivate.
Click Restore.
You can also reactivate a user by clicking the Activate icon (
) next to a user.
To restore all users listed on a page, click in the box located next to the Name column.
Click Restore.
To delete a user you need to first deactivate the user. Follow instructions in the Deactivating Users section to deactivate a user.
Click on the Users tab in the Enterprise Admin Portlet.
Click on the Active menu, and select No.
Click Search to display a listing of deactivated users.
Click on the box located next to the user you want to delete.
Click Delete.
You can also delete a user by clicking the Delete icon (
) next to a user.
To delete all users listed on a page, click the box located next to the Name column.
Click Delete.
A screen will appear asking if you want to permanently delete the selected users. Click OK to delete. Click Cancel if you do not want to delete the selected user.
Adminstrators and users with the
Impersonate function can conveniently review updates
performed to other users. For example, the adminstrator permissions
user Test LAX 2 to edit all users in the Liferay Los Angeles location
(see the Security and Permissions
section to learn how to assign permissions). To verify that the
permission has been correctly given, the administrator can sign in as
user Test LAX 2 to verify that the edit permission has been given or
the administrator can search for Test LAX 2 in the Enterprise Admin
portlet and click the Impersonate
icon (
). By using the Impersonate function, the adminstrator can
impersonate Test LAX 2 to review updates without
having to sign in as Test LAX 2.
User Groups can be used to group users to simplify the process of assigning roles and permissions to a number of users and to simplify the process of assigning a number of users to a community.
Click on the User Groups tab in the Enterprise Admin Portlet.
A listing of user groups appears on the bottom of the screen. Click on a user group you want to view. NOTE: Clicking on a user group will only display the name and description of the group. To actually view the users associated with the user group, click on the Assign icon.
To search for user groups, click on the User Groups tab in the Enterprise Admin Portlet.
Type a user group name in the "Name" input field.
Click Search.
Click on the User Groups tab in the Enterprise Admin Portlet.
Click Add.
Enter a name for the user group in the Name input field.
Click Save.
To add additional user groups, repeat steps 1-5.
To edit user group information, click on the User Groups tab in the Enterprise Admin Portlet.
Locate the user group you want to edit. Click the Edit icon () on the right of the user group.
Type changes in the Name input field.
Click Save.
Click on the User Groups tab in the Enterprise Admin Portlet.
To delete a single user group, click on the Delete icon (
) to the right of the user group. Click
OK to delete.
To delete multiple user groups, check the boxes located to the left of the user groups you want to delete.
Click the Delete button.
To delete all user groups listed on a page, check the box located next to the Name column.
Click the Delete button.
A screen will appear asking if you want to permanently delete the selected user groups. Click OK to delete. Click Cancel if you do not want to delete the selected user groups.
Click on the User Groups tab in the Enterprise Admin Portlet.
Click on the Assign icon
(
) to the right of the user group. For this
example, assume the Assign icon
for the Liferay San Francisco Users user group was clicked. The
following screen is displayed.
Click on the Available tab to display a list of all available users in the system. For this example, we are only interested in the users with "SFO" in their name.
Search for the desired users using the search form. For this example, enter "sfo" into the Last Name input field and click Search.
Check the boxes to the left of the desired users. If you would like to select all of the users on the page, check the box next to the Name column.
Click the Update Associations button.
To confirm the desired users were successfully associated with the user group, click on the Current tab.
Various functions can be performed to your organization and to location and users that belong to your organization.
Click on the Organizations tab in the Organization Admin portlet to display the Organization Screen.
Your organization appears on the bottom of the Organization Screen. Click on the organization to view.
To edit your organization, click on the Organizations tab in the Organization Admin Portlet.
Click the Edit icon
() located to the right of the organization
listing.
Enter changes in the Name input field. Select from the Country, Region, and Status menu to make changes.
Click Save.
To view a location, click on the Locations tab in the Organization Admin Portlet.
A listing of locations appears on the bottom of the Locations Screen. Click on a location you want to view.
A location information screen will appear.
You can also view locations through the Organization Screen:
Click on the Organization tab in the Organization Admin Portlet.
Click on the View
Location icon (
) located to the right of your
organization.
Click on a location to view.
To search for locations that belong to your organization, click on the Locations tab in the Organization Admin Portlet.
Type location information in the text boxes and select from the menu options.
Click Search.
To add locations to your organization, click on the Locations tab in the Organization Admin Portlet.
Click Add.
Enter location information in Name input field.
Select from the Country, Status, and Region menus.
Click Save.
To add additional locations, repeat steps 1-5.
You can also add locations through the Organization Screen:
Click on the Organization tab in the Organization Admin Portlet.
Click on the Add Location
icon (
) located to the right of the
organization.
Enter the location’s information in the input fields and select from the menus.
Click Save.
To edit locations that belong to your organization, click on the Locations tab in the Organization Admin Portlet.
Locate the location want to edit. Click the Edit icon () located to the right of the location
listing.
Type changes in the Name input fields. Select from the Country, Region, and Status menu to make changes.
Click Save.
You can view all users that belong to your organization or view users that belong to a specific location.
Click on the Users tab in the Organization Admin Portlet.
A listing of users appears on the bottom of the Users Screen. Click on a user you want to view. To view additional users, click on the page numbers to see additional user listings.
You can also view users through the Organization Screen:
Click on the Organization tab in the Organization Admin Portlet.
Click on the View
Users icon ( ) located to the right of the
organization.
Click on a user to view.
To search for users that belong to your organization, click on the Users tab in the Organization Admin Portlet.
Type user name in the input fields and select from the menu.
Click Search.
To add users to your organization, click on the Users tab in the Organization Admin Portlet.
Click Add.
Enter user’s information in the input fields and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
You can also add users through the Organization Screen:
Click on the Organizations tab in the Organization Admin Portlet.
Click on the Add User
icon () located to the right of the
organization.
Enter user’s information in the input fields and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
To edit user information, click on the Users tab in the Organization Admin Portlet.
Click on the user you want to edit.
Type changes in the First Name, Middle Name, Last Name, Email, and Job Title input fields. Select from the Prefix, Suffix, Birthday, Gender, Location menus to make changes.
Click Save.
To deactivate users, click on the Users tab in the Organization Admin Portlet.
Click on the box located next to the user you want to deactivate.
Click Deactivate.
To deactivate all users listed on a page, click the box located next to the Name column. Click Deactivate.
A screen will appear asking if you want to deactivate the selected users. Click OK to delete. Click Cancel if you do not want to deactivate the selected users.
Click on the User Groups tab in the Organization Admin Portlet.
A listing of user groups appears on the bottom of the screen. Click on a user group you want to view. NOTE: Clicking on a user group will only display the name and description of the group. To actually view the users associated with the user group, click on the Assign icon.
To search for user groups, click on the User Groups tab in the Organization Admin Portlet.
Type a user group name in the Name input field.
Click Search.
To edit user group information, click on the User Groups tab in the Organization Admin Portlet.
Locate the user group you want to edit. Click the Edit icon () on the right of the user group.
Type changes in the Name input field and, optionally, the Description text area.
Click Save.
Click on the User Groups tab in the Organization Admin Portlet.
To delete a single user group, click on the Delete icon () to the right of the user group. Click
OK to delete.
To delete multiple user groups, check the boxes located to the left of the user groups you want to delete.
Click the Delete button.
To delete all user groups listed on a page, check the box located next to the Name column.
Click the Delete button.
A screen will appear asking if you want to permanently delete the selected user groups. Click OK to delete. Click Cancel if you do not want to delete the selected user groups.
Click on the User Groups tab in the Organization Admin Portlet.
Click on the Assign icon
(
) to the right of the user group. For this
example, assume the Assign icon
for the Liferay San Francisco Users user group was clicked. The
following screen is displayed.
Click on the Available tab to list all of the available users in the system. For this example, we are only interested in the users with "SFO" in their name.
Search for the desired users using the search form. For this example, enter "sfo" into the Last Name input field and click Search.
Check the boxes to the left of the desired users. If you would like to select all of the users on the page, check the box next to the Name column.
Click the Update Associations button.
To confirm the desired users were successfully associated with the user group, click on the Current tab.
Various functions can be performed to your location and users that belong to a location.
To view your location, click on the Locations tab in the Locations Admin portlet.
Your location appears on the bottom of the Location Screen. Click on the location to view.
You can view your organization’s services, email addresses, addresses, phone numbers, websites, and comments.
Click on the Organization tab in the Location Admin Portlet.
Click on the organization that appears on the bottom of the screen.
Click on the Users tab in the Location Admin Portlet.
A listing of users appears on the bottom of the Users Screen. Click on a user you want to view. To view additional users, click on the page numbers and click on a user you want to view.
You can also view users through the Location Screen:
Click on the Location tab in the Location Admin Portlet.
Click the View Users
icon () located to the right of the
location. A User Screen will appear.
Click on a user to view.
You can also view users through the Organization screen:
Click on the Organization tab in the Location Admin Portlet.
Click on the View
User icon () located to the right of the
organization.
Click on a user to view.
You can search for a user listed or not listed on the display.
Click the Users tab in the Location Admin Portlet.
Type user name in the input fields and select from the menu.
Click Search.
To add users, click on the Users tab in the Location Admin Portlet.
Click Add.
Enter user’s information in the input fields and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
You can also add user through the Organization Screen:
Click on the Organizations tab in the Location Admin Portlet.
Click on the Add User
icon () located to the right of the
organization.
Enter user’s information in the input fields and select from the pull down menus.
Click Save.
To add additional users, repeat steps 1-4.
To edit user information, click on the Users tab in the Location Admin Portlet.
Click on the user you want to edit.
Type changes in the First Name, Middle Name, Last Name, Email, and Job Title input fields. Select from the Prefix, Suffix, Birthday, Gender, Location menus to make changes.
Click Save.
To deactivate users, click on the Users tab in the Location Admin Portlet.
Click on the box located next to the user you want to deactivate.
Click Deactivate.
To deactivate all users listed on a page, click the box located next to the Name column. Click Deactivate.
A screen will appear asking if you want to deactivate the selected users. Click OK to delete. Click Cancel if you do not want to deactivate the selected users.
Table of Contents
This chapter will provide a reference for administering communities within Liferay Portal 4. It will include a discussion of how to create and manage communities, as well as how to create and manage the pages and users within a community.
A community is defined as 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). Communities are entities in and of themselves -- they do not belong to a specific organization or location.
A community contains a collection of pages. Each page consists of one or more portlets. Every community must have at least one page (represented by tabs) to be active, but there is no limit to how many pages it can have. Users can be assigned directly to a community or indirectly via an organization, location, or user group. User assignments will be discussed in a later section. Communities can either be open or closed. Open communities allow a user to join or leave them at any time without any type of approval from Administrators. Closed communities can only receive new users who are explicitly assigned by Administrators. These concepts will also be discussed in a later section.
Once a user has been assigned either directly or indirectly to a community and assuming that community has at least one page defined, that user will see the community appear as an item in the My Places menu. By clicking on that menu item, the user will be taken to the selected community.
Communities are managed via the Communities Portlet. This portlet can be used to create, update, and delete communities; control the permissions of communities (including permission delegation); manage the pages of communities; assign users to communities (either directly or indirectly); and join or leave open communities. The pages of a community can either be managed via the Communities Portlet or by using the Add Content and Page Settings links. Examples of how all this works are provided in later sections.
As a general rule, objects in the portal can only belong to one community. For example, if a Message Board portlet is added to the "Support" community, all of the topics created through that portlet belong only to the "Support" community. There are only a few objects that do not belong to a single community such as organizations, locations, and user groups. These exception objects span all communities.
The Communities Portlet allows Administrators the ability to create and manage communities and their associated pages. Regular users can use the Communities Portlet to join or leave open communities
Log in to the portal as an Administrator
Add the Communities portlet to your page (if it doesn't already exist) by clicking on the Add Content link, searching for "Communities", clicking the Add button next to the portlet, and clicking the Finished button). Click on the Current tab in the Communities portlet. The following screen is displayed.
In the screen above, notice that a listing of the current communities that the user belongs to appears on the bottom of the screen. If you were to click on the Available tab, you would see a listing of all the available communities that exist in the system.
To search for communities on either the Current or Available tab, type a community name in the "Name" input field.
Click Search.
On either the Current or Available tab, click Add.
Enter a name for the community in the Name input field.
Optionally, enter a description for the community in the Description text area. Check the Open box if you want users to be able to join and leave this community on their own.
Click Save.
To add additional communities, repeat steps 1-4.
On either the Current or
Available tab, locate the
community you want to edit. Click the
Edit icon () on the right of the community.
Type changes in the Name input field and, optionally, the Description text area and the Open checkbox.
Click Save.
Without pages, a community is just an empty shell. All portlets in the portal are displayed on pages. They can be thought of as desktops on which you put your portlet applications. The desktops can be shared with other users or they can be restricted for your own personal use. By default, if a user is given the Power User role, that user is given a personal community that only he/she can access, and he/she has permissions to do anything in that community. Under the My Places menu, that community will appear as the user's name.
Click on the Pages icon
(
) to the right of the community. A screen
similar to the following is displayed.
In the screen above, notice that the pages that belong to the Test community are displayed in a tree structure on the left. Also notice that every page can have child pages. To actually view these pages in the portal, use the My Places menu to navigate to the Test community. The following screen is displayed.
In the screen above, notice that every top level page represented in the tree structure is represented by a tab in the portal. Also, every child page is represented in the Navigation portlet. The Navigation portlet is the only means to navigate to pages that are not at the top level. Therefore, make sure you put an instance of the Navigation portlet on every page that is not top level.
Go back to the Communities portlet, and click on the Pages icon to the right of the community to which you want to add a page.
Decide if you want to add a Public or Private page.
A public page is a page in your community that can be accessed by guests. As long as the guest has the appropriate URL (Friendly URLs will be discussed in the next section), the guest has permission to access any public page.
A private page is a page in your community that can only be accessed by logged in users who are part of your community. If a user is not logged in (i.e., the user is a guest) or if a user does not belong to your community, then the user cannot access your private page.
If you would like to create a public page, make sure the Public tab is selected. If you would like to create a private page, click on the Private tab.
In the left-hand tree structure, click on the node that
should be the parent of your new page. If you want to create a
top level page, make sure the community name is selected (it has
the 
icon to the left of it). If you want to
create a child page, make sure the appropriate parent page is
selected.
Click on the Children tab.
Type the name of the new page in the Name input field. Optionally, you can change the Type and Hidden settings.
Click on the Save button.
Optionally, you can use the up and down arrows underneath the main form to update the display order of the child pages.
Use the My Places menu to go to your community, and click on the tab for your new page if it's a top level page, or use the Navigation portlet to get to your new page if it is a child page.
Use the Add Content link to add portlets to your new page.
Go back to the Communities portlet, and click on the Pages icon to the right of the community for which you want to edit a page.
In the left-hand tree structure, find the page you want to edit and click on it.
Click on the Page tab.
You now have the option to change the Parent of the current page, rename the current page, change the display language of the current page, change the type of the current page, and change whether the current page is hidden or not. After making your changes, click the Save button.
You can also provide a Friendly URL for this page. Normally, portal URLs are very long and difficult to read because so many parameters are passed in through the URL. However, you can give your page a Friendly URL to make it easier to read and access.
Before you can give your page a Friendly URL, your community must have a Friendly URL. Click on the community name in the left-hand tree structure, click on the Page tab, and put in a Friendly URL for your community (it must start with "/"). Click the Save button.
Now go back to the page you're editing, click on the Page tab, and put in a Friendly URL for your page (it must also start with "/"). Click the Save button.
If everything was done correctly, you can now access your page using the following URL pattern:
http://server-name/web/community-friendly-url/page-friendly-url
If you already have a page in your community that is set up exactly like you want your current page set up, then you can use the Copy Page function. Just select the page that you want to copy from the drop-down next to Copy Page and click the Save button. Your current page will be an exact copy of the page you selected except for the page's name.
An exhaustive discussion of page permissions is provided in Chapter 3. In particular, see section 3.9.3
Go back to the Communities portlet, and click on the Pages icon to the right of the community for which you want to delete a page.
In the left-hand tree structure, find the page you want to delete and click on it.
Click on the Page tab.
Click on the Delete button.
Go back to the Communities portlet, and click on the Pages icon to the right of the community for which you want to manage the look and feel for a page.
In the left-hand tree structure, find the page you want to change the look and feel for and click on it.
Click on the Look and Feel tab.
You now have the option to select a new Theme or Color Scheme by clicking on the desired radio buttons.
Go back to the Communities portlet, and click on the Pages icon to the right of the community for which you want to import/export pages.
Click on the Import / Export tab.
If you click on the Export button, it will export all of the pages, their layouts, their configurations, their look and feel, and their permissions to a LAR file (Liferay ARchive). By default, it uses the current timestamp as the name of the LAR file, but you have the option to change it. After you click the Export button, you will be prompted with a dialog window asking where to save the file.
You can also import a LAR file into your current community. BE VERY CAREFUL, however, because importing a LAR file will overwrite any existing pages with the pages configured in the LAR file. To import a LAR file, click on the Browse button, find the LAR file on your hard drive, click the Open button, and then click the Import button.
Users can either be assigned directly or indirectly to a community. Both methods of assignment will be discussed below.
Go to the Communities portlet, and click on the Assign icon to the right of the community for which you want to assign users. The following screen is displayed
When a community is first created, only the user who created the community is assigned to it (in this case, Joe Bloggs). Click on the Available tab.
Use the search form to search for the users that you want to directly assign to this community.
Check the boxes to the left of the users that you want to directly assign to this community.
Click the Update Associations button.
Alternatively, users can directly assign themselves to open communities by joining them. See section 2.5.1 below.
Go to the Communities portlet, and click on the Assign icon to the right of the community for which you want to assign users.
Click on the Available tab.
Click on the Organizations, Locations, or User Groups tab.
Use the search form to search for the organizations/locations/user groups that you want to assign to this community. In other words, all of the members of your selected organizations/locations/user groups will be indirectly assigned to this community via a link. However, for all intents and purposes, the users will function as members of the community.
Check the boxes to the left of the organizations/locations/user groups that you want to assign to this community.
Click the Update Associations button.
Click on the Available tab.
Assuming a community is open, it will have a Join icon (
) to the right of the community.
Click on the Join icon.
Assuming that community already has pages configured for it, the My Places menu will now have an entry for the community you just joined. Click on that community's name, and you will be able to navigate to it.
Click on the Current tab.
Assuming there is an open community that you already
joined, it will have a Leave
icon (
) to the right of the community.
Click on the Leave icon.
The community you just left will no longer appear in the My Places menu, and you will no longer have access to it.
The Page Settings link functions almost exactly like the Pages icon in the Community Portlet. The following are the only differences:
The Page Settings link does not have a Public and Private tab. When you click on the Page Settings link, you only have access to manage the pages for the current community you're in. For example, if you're in the public "Support" community, you only have access to manage the public pages in the "Support" community, and if you're in the private "Support" community, you only have access to manage the private pages in the "Support" community.
If you click on the Import / Export tab in the Page Settings link, you only have the option to export and not import. This is because if you were given the option to import, you would overwrite all of the communities pages including the current page that you're on.
When you click on the Page Settings link, the current page is automatically selected in the left-hand tree structure
Table of Contents
This chapter will provide a reference for administering permissions for existing portlets and objects within Liferay Portal 4. Fine grain permissioning is one of the main new features of this release. The entire groups permissioning mechanism in Liferay has been reworked to allow for resource level permissions for users, communities, organizations, locations, and user groups. Please refer to the developers guide for implementation specifics.
Liferay Portal introduces a new security model that incorporates a fine-grained permissioning system to give administrators full control over access and privileges to portlets and objects within the portal. In all prior releases, permissioning was handled on a per portlet basis and was therefore limited in use and difficult to maintain. In this new release, the vast majority of permissioning logic has been extracted into its own framework so that the integration of permissioning into new portlets is minimal. In addition, the permissioning logic has been greatly enhanced so that administrators can finely tune security within the portal. This document begins by giving a high-level overview of all the entities involved in the security model. Some entities have always existed in the portal and should be familiar to administrators, but others are brand new and therefore require definition and explanation. Next, a discussion of all of the ways to assign permissions to users is given in a use case format.
Before using the new security model, an administrator must understand all the entities that compose the model. This chapter will define each of the entities and explain how they are related to the others.
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.
Table 5.1. Example Permissions
| Action | Resource | Explanation | |
| Message Board Category / Enterprise Scope | The user has permission to view any category in any message board in the enterprise | |
| Update | Message Board Category / "Developer" Community Scope | The user has permission to only update a category contained in a message board in the "Developer" community | |
| Delete | Message Board Category / "Java Issues" Individual Scope | The user has permission to only delete the "Java Issues" category (which happens to be in a message board in the "Developer" community) |
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:
Individual
Community
Enterprise
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:
Permission is directly assigned to the user
Permission is assigned to a community that the user belongs to
Permission is assigned to an organization that the user belongs to
Permission is assigned to a location that the user belongs to
Permission belongs to a role that is directly assigned to the user
Permission belongs to a role that is assigned to a community that the user belongs to
Permission belongs to a role that is assigned to an organization that the user belongs to
Permission belongs to a role that is assigned to a location that the user belongs to
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.
Now that the entities that compose the security model have been defined, this chapter explains how to administer permissions using these entities. Whenever possible, examples using the Message Board portlet are used to illustrate the steps an administrator would take to set permissions. In addition, the administrator’s view of the portlet is contrasted to an end user’s view of the portlet. The administration steps are presented in a use case format.
This discussion begins with a set of assumptions that set the environment for the rest of the discussion. It then proceeds to explain how to use the Enterprise Admin portlet to create a role, assign company and community permissions to the role, and then assign the role to users, communities, organizations, locations, and user groups. Finally, individual permissions at a portlet and object level are discussed.
Assumptions
For the purpose of our discussion, assume an Administrator has added a Message Board portlet to the Support community (the support community can be found by clicking on My Places drop-down menu). Also assume that a category called “Test Category" has been created, and the category contains three categories – “Test Category 1," “Test Category 2," and “Test Category 3." By default, all categories are viewable by users in the Support community. For this use case, assume that the permission to view Test Category 3 has been removed for all community users (see section 3.7 Assigning Individual Permissions to change the permissions for individual categories). The diagram below illustrates this scenario as seen from the Administrator’s view.
Also assume that “Test Category 3" contains a single thread. The following diagram depicts what an Administrator would see after clicking on the “Test Category 3" link.
For comparison purposes, assume an End User (Test LAX 2) that belongs to the Support community also logs in and views the Message Board portlet (by default, login = test.lax.2@liferay.com / password = test). The user will see the following after clicking on the “Test Category" link.
When compared with the Administrator’s view, it is clear that Test LAX 2’s view is much more limited in functionality. Test LAX 2 is missing several buttons and icons that the Administrator has. If Test LAX 2 were to click on the “Test Category 3" link, the following will appear.
Instead of seeing the thread like the Administrator, Test LAX 2 only sees a message saying the required permission to view the contents of this category has not been given. In the following sections, we will discuss the different ways administrators can give the End User additional permissions so the user can have greater control over the message board categories.
Goal: To create a role called “MBTopic Admin" using the Enterprise Admin portlet. This role will be used in subsequent use cases.
Begin by logging into the portal as an Administrator (defaults to the Joe Bloggs user) and adding the Enterprise Admin portlet to the desktop.
Click on the Roles tab. The following screen is displayed.
The screen above displays a list of current roles in the system. The administrator is able to search for a role by name if desired. Click on the Add button. The following screen is displayed.
The screen above allows the administrator to create a new role. Enter "MB Category Admin" in the Name input field and click the Save button. The system displays the following screen with a success message.
The administrator is returned to the role list screen. Notice that the new role has been created.
Goal: To assign a permission to the “MB Category Admin" role that allows users to view any message board category in the company (i.e., action = View, resource = Message Board Category, scope = Company).
From the Roles tab in the Enterprise Admin portlet, click on
the Delegate icon
(
) next to the “MB Categoryc Admin" role. The
following screen is displayed.
The purpose of the screen above is to find the resource to be acted upon. Every object in the portal is contained within a portlet. Therefore, the administrator must find the parent portlet of the object in question. Because the Message Board Category resource is to be acted upon, the administrator must first find the Message Board portlet. Use the numbers or the right arrow in the lower left corner of the screen to scroll through the portlets and find the Message Boards portlet. Click on the Message Boards link. The following screen is displayed.
The screen above presents two lists. First, it presents a list of the actions that can be performed on the portlet itself (in this case, a category can be added to the Message Boards portlet, the Message Boards portal can be configured, or it can be viewed). These are known as portlet permissions. Second, it presents a list of the "Resources" (i.e., objects) that are contained within the portlet. For this use case, the Category model is the target. Click on the Category link. The following screen is displayed.
The screen above presents a list of the actions that can be performed on the selected resource – in this case, the Message Board Categroy. The goal of this use case is to create a permission that allows all topics in the Enterprise to be viewable. Therefore, click on the Scope drop-down menu next to the View action and select “Enterprise." Then, click the Next button. The following screen is displayed.
The screen above provides a summary of the permissions that were just created for the “MB Categroy Admin" role. Click on the Finished button to return to the role list under the Roles tab.
Goal: To assign a permission to the “MB Category Admin" role that allows users to update any topic in the Support community’s message boards (i.e., action = Update, resource = Message Board Category, scope = Community, community = Support).
Repeat steps 1 – 3 of section 3.2. The following screen is displayed.
The screen above presents a list of the actions that can be performed on the selected resource – in this case, the Message Board Category. Notice that the View action already has its Scope field set to “Enterprise" because of the previous use case. It should be noted that scopes can be set for any number of actions on this screen before clicking the Next button. However, the goal of this use case is to create a permission that allows users to update any topic of a message board in the Support community. Therefore, click on the Scope drop-down menu next to the Update action and select “Community." Click the Next button. The following screen is displayed.
The purpose of the screen above is to allow the administrator to select one or more communities to associate with the selected action – in this case, the Update action. Since the Current tab is selected, it is clear that there are currently no communities associated with the Update action. Click on the Available tab. The following screen is displayed.
The screen above displays all of the available communities that can be associated with the Update action. If this had been a long list, the administrator could have searched for the desired community by its name. Check the checkbox next to the Support community, and click on the Update Associations button. The administrator is presented with the same screen, but a success message is also displayed. Click on the Current tab to confirm that the association was successful. The following screen is displayed.
The screen above confirms that the association was successfully made. Alternatively, if the administrator decides that this association should be discarded, uncheck the checkbox next to the community name and then click the Update Associations button. However, for this use case, this association is correct, so click the Next button to continue. The following screen is displayed.
Just as in the previous use case, this final screen displays a summary of the permissions that are now associated with the “MB Category Admin" role. Note that the previously created Enterprise scope permission is also included in the summary. Click on the Finished button to return to the role list under the Roles tab.
Goal: To assign the “MB Category Admin" role to the Test LAX 2 end user.
From the Roles tab in the
Enterprise Admin portlet, click on the Assign icon ( ) next to the “MB Category Admin" role. The
following screen is displayed.
In the screen above, notice that the Users tab and Current sub-tab are selected. This means the current users associated with the “MB Category Admin" role are being displayed. Currently, there are no users associated with this role. If there had been a long list of users, the administrator could have used the search form to search for particular users. However, the goal of this use case is to associate the “MB Category Admin" role with the Test LAX 2 user. Therefore, click on the Available tab in order to search for this user. The following screen is displayed.
The screen above lists all of the available users that can be associated with the “MB Category Admin" role. The search for the Test LAX 2 user could be performed in two ways. First, the administrator could use the search page numbers and the left/right arrows (below and to the left of the user list) to scroll through all the users and look for Test LAX 2. However, the more efficient approach would be to use the search form. In the Last Name field, type in “lax 2" and click on the Search button. The following screen is displayed.
The desired user is the first one in the list of search results. Check the checkbox next to Test LAX 2. If the use case called for multiple users to be associated with this role, any number of checkboxes could have been checked. Click the Update Associations button. The administrator is presented with the same screen, and a success message is also displayed. To confirm that the association was successfully created, click on the Current tab. The following screen is displayed.
From the screen above, it is clear that the association was successfully created. If the administrator decided that this association should be discarded, uncheck the checkbox next to the user’s name and click the Update Associations button.
Results
What have we accomplished in these four use cases? We created two permissions: Enterprise scope permission and Community scope permission—and we associated them with a role. We then associated the role with an end user. Therefore in theory, this end user should now have permission to perform these 2 actions on the selected resource. To test our theory, log into the portal as Test LAX 2. Go to the Support community using the My Places drop-down menu. Click on the “Test Category" link in the Message Boards portlet. Compare the "Before" and "After" screen shots below.
Before
After
Notice that now Test LAX 2 has the Update icons
(
) next to each of the topics. This is a
result of the section 3.3 use case. Now click on the “Test Topic
3" link. Compare the "Before" and "After" screen shots
below.
Before
After
Whereas before an error message appeared, now the user can actually view the thread. This is a result of the section 3.2 use case.
Assigning Roles to Other Entities
Alternatively, steps 1 – 5 in this use case could have been repeated for the Communities, Organizations, Locations, or User Groups tab. In fact, the exact same results could have been achieved by associating the “MB Category Admin" role with the appropriate community, organization, location, or user group instead of directly to the Test LAX 2 user.
Goal: To assign the “Add Category" portlet permission to the Test LAX 2 end user.
Assume that the Test LAX 2 user does not have permission to add a root category to the Message Boards portlet in the Support community. Based on this assumption, the portlet would appear like the following to Test LAX 2.
Notice in the screen above that there is no “Add Category"
button available. Log in to the portal as an Administrator and go
to the Support community located in the My
Places menu. Click on the Configuration icon (
) in the upper-right corner of the Message
Boards portlet. The following screen is displayed.
Click on the Permissions tab. The following screen is displayed.
In the screen above, notice that the User tab and Current sub-tab are selected. This means that the current users that have portlet permissions assigned to them are being displayed. Obviously, there are no users that have portlet permissions for this particular portlet. Click on the Available tab. The following screen is displayed.
Locate user Test Lax 2. The instructions are the same as steps 3-4 of section 3.4 except that after checking the Test LAX 2 checkbox, the administrator should click on the Update Permissions button. The following screen is displayed.
The screen above shows that the Test LAX 2 user currently has no portlet permissions assigned to her. Select Add Category from the Available select box and click on the right arrow to add it to the Current select box. If multiple users were selected in the previous step, the administrator can use the Previous/Next buttons to scroll through all of the selected users and assign portlet permissions to them. In this case, Test LAX 2 was the only user selected, so click on the Finished button. The following screen is displayed.
In the screen above, notice that the Test LAX 2 user has been updated with the “Add Category" portlet permission. To see this permission in effect, log in to the portal as Test LAX 2 and go to the Support community. The user should see the following screen.
Note that the Test LAX 2 user now has permission to add a root category to the Message Boards portlet.
Alternatively, steps 4 – 7 can be repeated for the Organizations, Locations, User Groups, Community, or Guest tab for assigning portlet permissions to each of these entities.
It should also be noted that portlet permissions are only applicable to the portlet instance for which they were configured. For example, Test LAX 2 can only add root categories to the message board in the Support community. Test LAX 2 would not be able to add root categories to message boards in other communities unless they were specifically configured as such.
Goal: To create a new Message Board Category in the Support community’s message board and assign default permissions to it.
Log in to the portal as an Administrator and go to the Support community. Click on the “Test Category" link in the Message Boards portlet, and then click on the Add Topic button. The following screen is displayed.
The screen above shows the form for creating a new topic. To set permissions for the category, click Configure.
Notice that all actions under Community are checked and the Guest View option is checked. By default, a new Message Board Category allows community members (in this case, Support community members) to view it, subscribe to it, and add messages to it, and it allows guests to view it (NOTE: The process for setting these defaults is beyond the scope of this user guide. Please refer to the programming guide for details).
Keep the default permissions checkboxes checked. Enter “Test Category 4" into the Name field, input the text verification code, and click the Save button. The administrator is returned to the topic list screen.
If the Test LAX 2 user were now to click on the “Test Category" link, the user would see the new “Test Topic 4" topic and would be able to view the contents of the topic and post a new thread/message to the category because of the community default permissions.
Goal: To assign a permission to user Test LAX 2 to delete the “Test Category 4" topic in the Support community’s Message Boards portlet.
Log in to the portal as Test LAX 2 and go to the Support community. Click on the “Test Category" link in the Message Boards portlet. The following screen is displayed.
In the screen above, notice that the user has Update permissions on all of the topics due to the use case in section 3.3. Now log in to the portal as an Administrator, go to the Support community, click on the “Test Category" link in the Message Boards portlet, and then click on the Permissions icon for the “Test Category 4" topic. The following screen is displayed.
In the screen above, notice that the Users tab and the Current sub-tab are selected. This means that the current users who have permissions for the “Test Category 4" topic are being displayed. Currently, only the Administrator (i.e., Joe Bloggs) has permissions on this category. Go to the Available tab, find the Test LAX 2 user, check the user’s checkbox, and click on the Update Permissions button. The following screen is displayed.
The screen above shows that the Test LAX 2 user currently has no assigned permissions. Select the Delete action from the Available select box and click on the left arrow to add it to the Current select box. If multiple users were selected in the previous step, the administrator can use the Previous/Next buttons to scroll through all of the selected users and assign permissions to them. In this case, Test LAX 2 was the only user selected, so click on the Finished button. The following screen is displayed.
In the screen above, notice that the Test LAX 2 user has been updated with the “Delete" permission. To see this permission in effect, log in to the portal as Test LAX 2, go to the Support community, and click on the “Test Category" link in the Message Boards portlet. The user should see the following screen.
In the screen above, note that the “Test Category 4" topic
now has a Delete icon
(
) next to it. Therefore, the Test LAX 2 user
has permission to delete the “Test Category 4" topic.
Alternatively, steps 3 – 6 can be repeated for the Organizations, Locations, User Groups, Community, or Guest tab for assigning individual permissions to each of these entities. Note that there is a special case for assigning individual permissions to Locations that requires a slightly different use case which is covered in the next section.
It should also be noted that very fine-grained permissioning can be obtained through using individual permissions. As this use case showed, administrators have the power to control objects within a portlet at a very micro level. For example, take the four topics in “Test Category." An administrator could easily decide that all users in the Liferay USA organization can post messages to “Test Category 1," but only members of the Support community can view the messages in “Test Category 2." In addition, only Test LAX 2 can update “Test Category 3," while anyone in the Liferay San Francisco location can update “Test Category 4." The possibilities are endless!
Goal: First, to assign a permission to the Liferay Los Angeles location that allows members of that location (including Test LAX 2) to delete the “Test Category 1 topic in the Support community’s Message Boards portlet. Second, to assign an "exclusive" permission to the Liferay Chicago location that removes the delete permission from all Liferay Los Angeles members.
Log in to the portal as Test LAX 2 and go to the Support community. Click on the “Test Category" link in the Message Boards portlet. The following screen is displayed.
In the screen above, notice that the user has Update permissions on all of the topics due to the use case in section 3.3, and has Delete permission on “Test Category 4" due to the use case in section 3.7. Now log in to the portal as an Administrator, go to the Support community, click on the “Test Category" link in the Message Boards portlet, and then click on the Permissions icon for the “Test Category 1" topic.
Now click on the Locations tab, and then click on the Available sub-tab. Check the Liferay Los Angeles checkbox and click on the Update Permissions button. The following screen is displayed.
The screen above shows that the Liferay Los Angeles location currently has no permissions assigned to it. Notice the “Permission exclusive to members of current location and community?" drop-down. Leave it defaulted to “No," but think about what this question might mean. It will be fully explained later.
Select the Delete action from the Available select box and click on the left arrow to add it to the Current select box. Click on the Finished button. The following screen is displayed.
In the screen above, notice that the Liferay Los Angeles location has been updated with the “Delete" permission and an Exclusive value of “No." This value will be explained later. To see this permission in effect, log in to the portal as Test LAX 2, go to the Support community, and click on the “Test Category" link in the Message Boards portlet. The user should see the following screen.
In the screen above, notice that “Test Category 1" now has a
Delete icon () next to it. Therefore, the Test LAX 2 user
has permission to delete “Test Category 1."
Now repeat steps 1 – 5 for the Liferay Chicago location. The Administrator’s screen should appear as follows.
…and Test LAX 2 should still see the same screen as before:
Now go back to the Administrator’s view, check the Liferay Chicago checkbox, and click the Update Permissions button. From the “Permission exclusive to members of current location and community?" drop-down menu, select “Yes" and click the Finished button. Now the Administrator’s screen looks like the following.
In the screen above, notice the “Exclusive" value for Liferay Chicago has now changed from “No" to “Yes." Go back to Test LAX 2’s view and refresh the screen. It should appear as the following.
In the screen above, notice the Test LAX 2 user no longer has permission to delete “Test Category 1."
Exclusive Permission Defined
Confused? Hopefully this discussion will clear things up.
Let’s consider what occurred in this use case. Initially, the delete permission for “Test Category 1" was added to the Liferay Los Angeles location. As expected, the Test LAX 2 user received the delete permission. Then, the delete permission for “Test Category 1" was added to the Liferay Chicago location. Though an explicit check was not made, it is assumed that this allowed all members of the Liferay Chicago location to also have delete permission. In other words, any member of either Liferay Chicago or Liferay Los Angeles had delete permission on “Test Category 1."
However, when the value of the “Permission exclusive to members of current location and community?" drop-down menu was changed from “No" to “Yes" for Liferay Chicago, suddenly Test LAX 2 lost the delete permission. Why?
By answering “Yes" to the question, the permission became an exclusive one. In other words, in order to have the delete permission on “Test Category 1," a user had to be a member of both the Liferay Chicago location and the Support community. Since Test LAX 2 was only a member of the Support community and not a member of the Liferay Chicago location, LAX 2 did not meet the criteria and was excluded from receiving the delete permission.
Exclusive permissions take precedence over all other permissions except permissions assigned directly to a user. Therefore, even if the delete permission had been assigned to the Liferay Los Angeles location and the Support community, or if the delete permission had enterprise scope and had been assigned to a role that was assigned to Test LAX 2, it wouldn’t have mattered. The exclusive permission would still have taken precedence, and Test LAX 2 would not have received the delete permission. However, if the delete permission had been assigned directly to the Test LAX 2 user, LAX 2 would have received the permission
Although exclusive permissions are not additive with other permissions, they are additive among themselves. In other words, if the “Permission exclusive to members of current location and community?” drop-down was changed from “No” to “Yes” for Liferay Los Angeles as well, Test LAX 2 would once again receive the delete permission. However, it should be noted that only Liferay Chicago and Liferay Los Angeles users would receive the permission, even if the delete permission was assigned to other users through other entities (e.g., via organization, via location, via community, via role, etc.).
So far in this discussion, it has been assumed that a user with the "Administrator" role has been creating roles and assigning permissions to various entities. However, it is also possible for an Administrator to delegate permissions to users which allow them to have certain administrative rights as well. The following sections will explain each of these scenarios using use cases.
Assumptions
For the purposes of this discussion, assume the Administrator has created a role called "Delegated Admin" and assigned it to the Test LAX 2 user. Also assume that the "Enterprise Admin" portlet and the "Communities" portlet have been added to the Support community.
Goal: To assign the Test LAX 2 user permissions to add communities, organizations, and roles to the system.
Log in to the portal as Test LAX 2 and go to the Support community. Click on the Current tab in the Communities portlet. The following screen is displayed.
In the screen above, notice the Test LAX 2 user has no way of adding a new community to the system. Now log in to the portal as an Administrator. Go to the Support community and click on the Roles tab in the Enterprise Admin portlet. Click on the Delegate icon next to the "Delegated Admin" role. The following screen is displayed.
Find the Portal link in the list and click on it. The following screen is displayed.
Choose "Enterprise" from the Scope drop-down next to the "Add Community" action. Click the Next button. The following screen is displayed.
The result of these steps is that any user with the "Delegated Admin" role can now add communities to the system. To confirm this, go back to Test LAX 2 and refresh the Current tab in the Communities portlet. The following screen is displayed.
In the screen above, notice there is now an Add button. We will add a new community in a subesquent use case. Now, as Test LAX 2, go to the Enterprise Admin portlet and click on the Organizations tab. The following screen is displayed.
In the screen above, notice there is no way for Test LAX 2 to add a new organization to the system. Go back to the Administrator and perform steps 2-4 again, only this time in step 3, choose "Enterprise" from the Scope drop-down next to the "Add Organization" action. These steps have enabled any user with the "Delegated Admin" role to have permission to add organizations to the system. To confirm this, go back to Test LAX 2 and refresh the Organizations tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice there is now an Add button. We will add an organization in a subsequent use case. Now, as Test LAX 2, click on the Roles tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice there is no way for Test LAX 2 to add a new role to the system. Go back to the Administrator and perform steps 2-4 again, only this time in step 3, choose "Enterprise" from the Scope drop-down next to the "Add Role" action. These steps have enabled any user with the "Delegated Admin" role to have permission to add roles to the system. To confirm this, go back to Test LAX 2 and refresh the Roles tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice there is now an Add button. We will add a role in a subsequent use case. Now, as Test LAX 2, click on the User Groups tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice there is no way for Test LAX 2 to add a new user group to the system. Go back to the Administrator and perform steps 2-4 again, only this time in step 3, choose "Enterprise" from the Scope drop-down next to the "Add User Group" action. These steps have enabled any user with the "Delegated Admin" role to have permission to add user groups to the system. To confirm this, go back to Test LAX 2 and refresh the User Groups tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice there is now an Add button. We will add a user group in a subsequent use case.
Goal: To understand the concept of a "Community Admin" and how a "Community Admin" can further delegate permissions to members of the community.
Log in to the portal as Test LAX 2 and go to the Support community. Click on the Current tab in the Communities portlet. As a result of the previous use case, Test LAX 2 has permission to add a new community. Add a new community called "Test". The Current tab in the Communities portlet should now look like the following screen.
In the screen above, notice that the Test community has several icons next to it. When a user creates a new community, that user automatically becomes the "Community Admin" of that community. Therefore, the user has permission to perform all functions to that new community.
To start, let's add some members to the Test community. Click on the Assign icon and associate users Test LAX 3, Test LAX 4, and Test LAX 5 with the community. Notice that Test LAX 2 is a member of the community by default. The Current tab under Assign should look like the following.
Now let's add some pages to the Test community. Click on
the return arrow, click on the Current tab in the Communities portlet,
and click on the Pages icon
(). Click on the Children tab and add three public pages
called "Test 1," "Test 2," and "Test 3." Go to the Test
community, click on the Test 1
tab, and add a Calendar portlet to the page using the Add Content link. Click on the Test 2 tab and add a Calendar portlet.
Finally, click on the Test 3
tab and add a Navigation portlet.
NIn step 2, we added the Test LAX 3 user as a member of the Test community. Log in as that user (by default, test.lax.3@liferay.com / password). Navigate to the Test community. The following screen is displayed.
In the screen above, notice that Test LAX 3 has no way of adding a new event to the calendar. Go back to Test LAX 2, and go to the Current tab in the Communities portlet in the Support community. Click on the Delegate icon next to the Test community. The following screen is displayed.
Click on the Calendar link in the list. The following screen is displayed.
In the screen above, we have to decide whether to delegate portlet permissions or to delegate resource permissions. In this case, we want to allow users to be able to add events to the calendar. This is a portlet permission, so click on the Next button. On the new screen, click on the Available tab. The following screen is displayed.
In the screen above, notice that we can only delegate permissions to members of the community. Check the "Test LAX 3" user and click on the Update Permissions button. On the next screen, give Test LAX 3 the "Add Event" permission and click on the Finished button. The following screen is displayed.
In the screen above, notice that Test LAX 3 now has the "Add Event" permission. This means that Test LAX 3 can now add an event to any Calendar portlet in the Test community. To confirm this, go back to Test LAX 3 and refresh the Test 1 tab in the Test community. The following screen is displayed.
In the screen above, notice that Test LAX 3 now has the Add Event button available. Now click on the Test 2 tab. Test LAX 3 also has permission to add events to this calendar. Alternatively, steps 7-9 could have been repeated using the "Event" resource to control permissions related to calendar events.
It should be noted that the preceding use case allowed the "Community Admin" to delegate permissions such that a user could add an event to any calendar in the Test community. Alternatively, the "Community Admin" could have delegated permissions such that a user could add an event to only an individual calendar in the "Test" community. Refer to section 3.5 for instructions on assigning individual portlet permissions.
Goal: To delegate permissions to users such that they will be able to manage pages within their communities.
Log into the portal as Test LAX 3 and navigate to the Test community. The following screen is displayed.
In another browser, log into the portal as Test LAX 2 and also navigate to the Test community. The following screen is displayed.
Compare the 2 screens. Notice that Test LAX 3 doesn't have the "Add Content" and "Page Settings" links in the upper right corner like Test LAX 2 does. In addition, Test LAX 3 doesn't have the portlet icons for Configuration, Minimize, Maximize, or Remove like Test LAX 2 does. Also, Test LAX 3 is not able to drag and drop the portlet like Test LAX 2 is able to.
Now, as Test LAX 2, navigate to the "Support" community and click on the Current tab in the Communities portlet. Click on the Permissions icon next to the "Test" community. Under the Users -> Available tab, find the Test LAX 3 user, Update Permissions, and add the "Manage Pages" permission to this user. The resulting page should appear like the following.
Go back to the Test LAX 3 user and refresh the Test 1 tab in the "Test" community. The following screen is displayed.
In the screen above, notice that the Test LAX 3 user now has access to the "Add Content" and "Page Settings" links. Test LAX 3 also has all the portlet icons (icons will appear when the cursor is placed on the top right region of the portlet) and is able to drag and drop portlets. This applies to all the pages within the "Test" community.
Alternatively, since Test LAX 2 was previously given the "Add Role" permission, Test LAX 2 could have created a role, assigned the role to Test LAX 3, clicked on the new role's Delegate icon, chosen the Communities portlet, chosen the Community resource, and given the "Manage Pages" permission at either Community or Enterprise scope. This would have achieved the same results as the previous steps in this use case.
Let's now assume that Test LAX 4 should be able to only add and manipulate portlets on the Test 2 page of the Test community. Log in as Test LAX 4, navigate to the Test community, and click on the Test 2 tab. The following screen is displayed.
In the screen above, notice that Test LAX 4 does not have the "Add Content" link and does not have the Configuration, Minimize, Maximize, and Remove icons for the portlet. Test LAX 4 also can not drag and drop the portlet. Now, as Test LAX 2, go to the Test community, and click on the "Page Settings" link. The following screen is displayed.
Click on the "Test 2" page in the tree structure on the left, then click on the Permissions button. Under the User -> Available tab, find Test LAX 4 and give that user Update permissions (by default, all users in the community are given "View" permissions -- click on the Community tab to see this). The resulting screen should appear as the following.
To see this permission in effect, go back to Test LAX 4 and refresh the Test 2 tab in the "Test" community. The following screen is displayed.
In the screen above, notice that Test LAX 4 now has the "Add Content" icon. The Minimize, Maximize, and Remove portlets icons appears when the cursor is pointed at the top right region of the calendar portlet. Test LAX 4 can now also drag and drop portlets. However, also notice that Test LAX 4 does not have the "Page Settings" link or the Configuration icon. The "Page Settings" link is only available to users who are Administrators, Community Admins, or have the "Manage Pages" permission. The Configuration icon is only available to users who are Administrators, Community Admins, or have the "Configuration" portlet permission. If Test LAX 4 were to go to the Test 1 or Test 3 tab, no "Add Content" link or portlet icons would be available.
Alternatively, since Test LAX 2 was previously given the "Add Role" permission, Test LAX 2 could have created a role, assigned the role to Test LAX 4, clicked on the new role's Delegate icon, chosen the Communities portlet, chosen the Page resource, and given the "Update" permission at either Community or Enterprise scope. This would have achieved the same results as the previous steps in this use case except that it would have applied to every page and not just the Test 2 tab.
Let's now assume that Test LAX 5 should not be able to view the Test 1 tab. Log in as Test LAX 5 and navigate to the "Test" community. The following screen is displayed.
In the screen above, notice that Test LAX 5 has access to all 3 tabs within this community. Now, go back to Test LAX 2, navigate to the "Test" community, click on the "Page Settings" link, and "Test 1" should already be selected in the tree structure on the left. Under the Page tab, click on the Permissions button. Click on the Community tab and remove the "View" permission. Now, no one in the community (except for the admins) can view the Test 1 tab. To confirm this, go back to Test LAX 5 and refresh the "Test" community. The following screen is displayed.
In the screen above, notice that the Test 1 tab no longer appears. If step 14 were repeated for the Test 2 and Test 3 tabs, Test LAX 5 would see the following screen upon trying to access the "Test" community.
Let's now assume that the Test 3 tab has several subpages, and the "Community Admin" (in our case, Test LAX 2) wants to show and hide certain subpages for Test LAX 5. Go back to Test LAX 2, go to the "Test" community, click on the "Page Settings" link, and create subpages for Test 3 according to the screen below.
Also as Test LAX 2, go to the Test 3 tab, click on the Child 2 link in the Navigation portlet, then click the "Add Content" link and add the Navigation portlet to this page. The following screen is diplayed.
In the screen above, notice that the subpages created in step 16 all appear here. As mentioned earlier, by default, newly created pages are viewable by all members of the community. To confirm this, go back to Test LAX 5 and refresh the Test 3 tab in the "Test" community. The Navigation portlet displays the "Test 3" link and its 3 children links. Click on "Child 2". Now the Navigation portlet appears exactly like the screen above.
Now we are going to hide the "Grandchild 1" and "Grandchild 2" subpages. Go back to Test LAX 2 and click on the "Page Settings" link. Using the left-hand tree structure, navigate to "Grandchild 1" and click on it. Under the Page tab, click on the Permissions button. On the next screen, click on the Community tab and remove the "View" permission. Repeat this step for the "Grandchild 2" subpage. Now go back to Test LAX 5 and refresh the Child 2 subpage in the "Test" community. The following screen is displayed.
In the screen above, notice that the "Grandchild 1" and "Grandchild 2" links no longer appear.
Goal: To delegate permissions to users so that they will be able to manage portlets within pages.
Section 3.5 explained how to assign individual portlet permissions for a portlet. The two most common portlet permissions are Configuration and View. If a user is given the Configuration permission, the user has permission to update the portlet's Setup, Look and Feel, and Permissions sections. If a user is given the View permission, the user has permission to view the contents of the portlet. Both permissions can be granted at the individual portlet level via the Configuration icon -> Permissions tab, or they can be granted at Enterprise or Community scope via a role.
In addition, if a user is given the Manage Pages permission for a community, that user has permission to update any portlets' Setup, Look and Feel, and Permissions sections within the community. In other words, it's as if the user has the Configuration permission for every portlet within the community.
Goal: To delegate permissions to users such that they will be able to manage organizations, locations, users, and user groups.
Log into the portal as Test LAX 2. Go to the "Support" community, and click on the Users tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice that Test LAX 2 has no permissions to do anything to the users. If Test LAX 2 tries to add, update, deactivate, or even view a user, eventually Test LAX 2 will see the following error screen.
Now, log into the portal as an Administrator, navigate to the Enterprise Admin portlet, and click on the Users tab. The following screen is displayed.
In the screen above, notice that the Administrator has all the available icons to update, permission, and deactivate the users. Go back to Test LAX 2 and click on the Organizations tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice that Test LAX 2 has permissions to View Users and View Locations associated with the organizations. Also, because of the use case in section 3.9.1, Test LAX 2 has permission to add an organization. However, Test LAX 2 does not have permission to do anything else. Now click on the Add button and create an organization called "Liferay Test Organization." After you click the Save button, you can optionally add other organization details like email addresses, website, phone numbers, etc. When you're done, click on the Organizations tab again. The following screen is displayed.
In the screen above, notice that Test LAX 2 has all available permissions on the "Liferay Test Organization" organization. Now, click on the Locations tab. The following screen is displayed.
In the screen above, notice that Test LAX 2 only has permission to View Users for the locations. Test LAX 2 does not have permissions to do anything else except add a location to the "Liferay Test Organization" organization. To confirm this, click on the Add button, use "Liferay Test Location 1" for the name field, select "Liferay USA" for the organization, fill out the other fields, and click the Save button. The following screen is displayed.
The error screen is displayed because Test LAX 2 does not have permission to add locations to the "Liferay USA" organization. Repeat step 7, only this time, select the "Liferay Test Organization" organization. After you click the Save button, again you have the option to provide additional location details. When finished, click on the Locations tab. The following screen is displayed.
In the screen above, notice that Test LAX 2 has full permission rights over the "Liferay Test Location 1" location. Repeat step 8 to create 2 more locations under the "Liferay Test Organization" called "Liferay Test Location 2" and "Liferay Test Location 3."
Let's now assume that Test LAX 3 should be the "Location User Admin" for the "Liferay Test Location 1" location. This means Test LAX 3 should be able to manage any user in this location. As Test LAX 2, click on the Permissions icon next to the "Liferay Test Location 1" location. Under the Users -> Available tab, find and check Test LAX 3, and click the Update Permissions button. The following screen is displayed.
In the screen above, notice the list of available permissions. The following list defines each in the context of a location:
Add User - You can add a user to this location
Delete - You can delete this location
Delete User - You can delete any user in this location
Permissions - You can control the permissions for this location
Permissions User - You can control the permissions for any user in this location
Update - You can update this location
Update User - You can update any user in this location
View - You can view the details of this location
View User - You can view the details for any user in this location
Give Test LAX 3 all of the available user permissions (i.e., Add User, Delete User, Permissions User, Update User, and View User. Do not add Delete, Permissions, Update, and View) and click the Finished button. Now, log into the portal as Test LAX 3, navigate to the "Support" community, and click on the Users tab in the Enterprise Admin portlet. Click on the Add button. Create a user with the following attributes:
First Name = Test
Last Name = User 1
Email Address = test.user.1@liferay.com
Organization = Liferay Test Organization
Location = Liferay Test Location 1
After clicking the Save button, click on the Users tab and search for Test User 1. The following screen is displayed.
In the screen above, notice that Test LAX 3 has all the permissions for the "Test User 1" user. Now click on the Locations tab. The following screen is displayed.
In the screen above, notice that the Test LAX 3 user has permission to add a user to the "Liferay Test Location 1" location.
Now let's assume Test LAX 4 should be the "Organization Admin" for the "Liferay Test Organization" organization. This means Test LAX 4 should be able to manage all users within the organization (which means the ability to manage any user in any location in the organization) and manage the organization itself (which means the ability to update/delete the organization as well as add new locations to the organization). Go back to Test LAX 2 and click on the Organizations tab in the Enterprise Admin portlet. Click on Liferay Test Organization's Permissions icon. Under the Users -> Available tab, find and check the Test LAX 4 user, and click on the Update Permissions button. The following screen is displayed.
In the screen above, notice the list of available permissions. The following list defines each in the context of an organization:
Add Location - You can add a location to this organization
Add User - You can add a user to any location in this organization
Delete - You can delete this organization
Delete User - You can delete any user in any location in this organization
Permissions - You can control the permissions for this organization
Permissions User - You can control the permissions for any user in any location in this organization
Update - You can update this organization
Update User - You can update any user in any location in this organization
View - You can view the details of this organization
View User - You can view the details for any user in any location in this organization
Give Test LAX 4 all of the available permissions and click the Finished button. Now, log into the portal as Test LAX 4, navigate to the "Support" community, and click on the Users tab in the Enterprise Admin portlet. Click on the Add button. Create a user with the following attributes:
First Name = Test
Last Name = User 2
Email Address = test.user.2@liferay.com
Organization = Liferay Test Organization
Location = Liferay Test Location 2
After clicking the Save button, click on the Users tab and search for Last Name = "User". The following screen is displayed.
In the screen above, notice the Test LAX 4 user has all permissions (except the impersonate function for "Test User 1") for both the "Test User 1" and "Test User 2" users. This is because Test LAX 4 was given permission to manage any user in any location in the organization. Now click on the Organizations tab. The following screen is displayed.
In the screen above, notice the Test LAX 4 user has all permissions for the "Liferay Test Organization" organization (including "Add Location"). Now click on the Locations tab. The following screen is displayed.
In the screen above, notice that Test LAX 4 has permission to add users to any location in the "Liferay Test Organization" organization.
Alternatively, all of the permissions discussed in this use case could have been controlled at an Enterprise or Community scope via roles. The Enterprise Admin portlet has four resources available for the permission assignments -- Location, Organization, User, and User Group -- as shown in the following screen.
Goal: To delegate permissions to users such that they will be able to manage roles.
Log into the portal as Test LAX 2, navigate to the "Support" community, and click on the Roles tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice that Test LAX 2 has no permission to do anything to the existing roles. Test LAX 2 only has permission to add a new role. Now log into the portal as an Administrator, navigate to the Enterprise Admin portlet, click on the Roles tab, and click on the Permissions icon next to the "Delegated Admin" role. Under the Users -> Available tab, find and check the Test LAX 2 user, and click the Update Permissions button. Give the Test LAX 2 user the "Add Permissions", "Assign Users", and "View" permissions and click the Finished button. Now go back to Test LAX 2 and refresh the Roles tab in the Enterprise Admin portlet. The following screen is displayed.
In the screen above, notice the Test LAX 2 user now has permission to delegate permissions and assign this role to users.
NOTE: Be very careful when assigning the "Add Permissions" permission to a role. This essentially gives any user who has this role Administrator access since the user can add any permission in the system to their role.
Alternatively, all of the permissions discussed in this use case could have been controlled at an Enterprise or Community scope via roles. The Enterprise Admin portlet has a Role resource available for the permission assignments.
Portal users who have the "Power User" role are given a personal community or "Desktop". Users are defaulted to this community when they log in. A user's personal community can not be seen or accessed by any other user including Administrators. Within the personal community, the user functions as an Administrator and has all permissions on all pages, portlets, and resources.
Table of Contents
The functionalites of each tab in the Admin Portlet, except for the Auto Deploy tab, will be explained in this section.
From the Server tab you can shutdown the server.
Click More Options.
Input the number of minutes before the server will be shutdown in the Number of Minutes box.
Notes can be added in the Custom Message box.
Click Shutdown.
To cancel shutdown, enter 0 and click Shutdown.
An enterprise’s information can be viewed or edited from the Enterprise tab. The Mail Domain box contains the domain names that the server will recognize.
The default language, time zone, and resolution can be changed in the Display section.
Click Save after making any changes.
The Portlets tab shows the minimum required roles for an individual to access a portlet. For example, in the case of the Blogs portlet, a person must have the minimum required role of a User or Power User. Guests will not have access to this portlet.
To change the minimum required roles, click on the portlet and make any changes in the text box, and click Save.
Under the User tab are six sub-tabs:
The Live Session tab shows a list of all users who are currently logged in.
To end a user's session, click on the user and click Kill Session.
With the General tab selected, the mode of authentication, whether a user signs in by email address or by user ID, can be selected on the first line. The second line provides the option for users to automatically login. The third line provides the option to allow strangers to create accounts.
Click Save after making any changes.
Under the Default Communities and Roles tab, you can enter default community names that are associated with newly created users.
In the second box, you can enter default roles that are associated with newly created users.
Click Save after making any changes.
In the first box, you can reserve user ID names that can not be used by users.
In the second box, you can reserve user email addresses.
Click Save after making any changes.
Additional mail host names besides liferay.com can be entered here.
Click Save after making any changes.
From the Emails tab, with the Email From sub-tab selected, you can enter the name and email address of automatically generated emails.
With the User Added Email sub-tab selected, you can make changes to the default message that is automatically sent when accounts are created. To disable new account emails, uncheck the Enabled box.
With the Password Sent Email tab selected, you can make changes to the default message that is automatically sent when a new password is created. To disable new account emails, uncheck the Enabled box.
Click Save after making any changes.
Table of Contents
Click Add Category.
Enter a name and a description.
Set Permissions by clicking on Configure.
To configure additional permissions, click on More.
Enter the Text Verication code and click Save.
To create sub-categories, click on the newly created category and click Add Category.
Enter a name and description, and click Save.
To edit a category or thread, click on the Edit (
) button located next to the category or
thread you want to edit.
To delete a category or thread, click on the Delete (
) button next to the category or thread you
want to delete.
To be notified by email when a new message has been posted or
updated, click Subscribe
(
).
To unsubscribe, click Unsubscribe (
).
To configure the subscription function, click on Configuration (
).
With the Setup tab selected, there are four sub-tabs that appear.
With the Email From tab selected, you can change the name and address of the automatically sent emails.
The Message Added Email tab allows the Administrator to edit the email that is sent whenever a posting is added. To disable email alerts, uncheck the Enabled box. Click Save after making any changes.
The Message Updated Email tab allows the Administrator to edit the email that is sent whenever a posting is updated. To disable email alerts, uncheck the Enabled box. Click Save after making any changes.
With the Ranking tab selected, the Administrator can manage the ranking profiles. The default setting assigns the youngling ranking to a message board poster with 0 to 24 postings. A poster with 250 to 499 postings will be assigned a Jedi Master ranking. The Administrator can change the ranking names and posting number requirements by making changes directly and clicking Save.
| Note |
|---|---|
Starting with Liferay 4.2 it is also possible to activate Liferay SMTP events to allow users to respond to mails sent by the message boards. In order to avoid HTML problems when posting through replies the mails are now sent in plain text. |
Click the Statistics to see posting statistics.
Click Top Posters to see a list of most active users.
To set the the feeds that you want displayed in the RSS portlet,
click on Preferences
(
).
Enter one URL per line.
Select the number of enteries per feed that will be displayed.
Save.
Table of Contents
Once the user logs in to the portal and adds the workflow portlet to her page, the user will see something similar to the following:
If user clicks on the Definitions tab, the following will be displayed:
The Definitions tab displays all of the workflows that have been deployed in the system. To deploy a workflow, click on the Add button. The user will see the following screen:
At this point, the user can paste in the contents of a definition XML (see jbpm-web.war/WEB-INF/definitions for examples) and click the Save New Version button. If the XML is invalid, an error message will be displayed. If the XML is valid, it will be deployed, the user will be returned to the Definitions tab, and a success message will be displayed.
Because business processes may change over time, every version of
the workflows is maintained. To edit an existing version, click on the
Edit icon (
) located next to the definition name. Update the
XML in the text area, and click the Save New
Version button. The new version number will be incremented by
one from the previous version. To start a new instance of a workflow
definition, click on the Add Instance
icon (
). A new instance will appear on the Instances tab. To view all the instances of a
particular definition, click on the View
Instances icon (
). Finally, the user can also search for a
definition by name using the Definition
Name input box.
After a definition is deployed and an instance of that definition is started, it is up to the user to manage the life cycle of the instance. Instance management is controlled from the Instances tab. Below is an example of what the user might see:
The Instances tab displays every instance of every version of every workflow deployed in the system. They are listed alphabetically by “Definition Name” followed by “Start Date” in descending order. The search form at the top of the screen allows the user to find specific instances to manage. In particular, the Hide instances that have already ended checkbox allows the user to display only active, running instances. The date ranges also allow the user to search by “Start Date” and/or “End Date” (NOTE: Date ranges are inclusive of the day. For example, if the “Start Date” range was set to January 27, 2007 – January 27, 2007, then only instances that were started between January 27, 2007, 12:00am to January 27, 2007, 11:59pm would be displayed). The first row for each instance describes the state of the instance. Any subsequent rows in the instance define tasks associated with the current state. Often times, the current state and current task have the same name. In the example screenshot above, notice that websale version 2.0 is currently in the “Perform shipping and payment” state, and it has two outstanding tasks associated with it – “Wait for shipment to be delivered” and “Wait for money.”
The right-most column in the results table displays the actions the current user can perform on the given instance in its current state. The table below shows all of the possible actions and what each means:
| Action | Explanation |
| Blank | 3 possibilities: 1) The user does not have the appropriate role/swimlane to perform an action on the instance in its current state 2)The user does not have permissions to perform an action 3)The instance has already ended |
Manage icon ( ) | The user directly has the appropriate role/swimlane to perform an action or the user belongs to a group which has the appropriate role/swimlane. If the user clicks on the Manage icon, she will be taken to a form which must be submitted to complete the task. See section 3.3 for more details |
Signal icon ( ) | The instance is currently in a wait state and must be “signalled” to continue. Typically, signals come from eternal processes (e.g. the arrival of a package and the successful update of a legacy system) and are not manually entered by a user. However, in the case that user intervention is required, the “Signal” icon is available. |
| Waiting on sibling tokens to complete | This only occurs when the process has forked into multiple subprocesses. In order for the main process to continue, all of the subprocesses must complete. As each of the subprocesses completes, they will go into this state. Once all subprocesses complete, the main process will continue like normal. |
Task management is controlled from the Tasks tab. Below is an example of what the user might see:
The Tasks tab displays every task that has either been assigned directly to the user or to the group/role pool that the user belongs to. They are listed by “Create Date” in ascending order, and the tasks assigned directly to the user are listed before the tasks assigned to the user’s pool (if the “Assigned To” column is blank, that means the task is open to the pool). The search form at the top of the screen allows the user to find specific tasks to manage. In particular, the Hide tasks that have already ended checkbox allows the user to display only active tasks. The date ranges also allow the user to search by task “Create Date,” “Start Date,” and/or “End Date.” The user can also choose to only display tasks assigned directly to her, tasks assigned to her pool, or all tasks assigned to either by using the “Assigned To” drop-down.
The right-most column in the results table displays the actions
the current user can perform on the given task. It will either be blank
or the Manage icon (
) will appear. The logic to determine which of
these will be displayed is exactly the same logic described in the table
in section 3.2.
If the user clicks the Manage icon, a form similar to the following will be displayed:
These task forms are generated from the control variables associated with the task and defined in the definition XML. Depending on the data type, the corresponding element is created in the form. Required fields are denoted by a red asterisk. If invalid data is submitted, the user will be returned to the form with error messages next to each of the invalid fields. If all data is valid and the form is submitted, the user will be returned to the Tasks tab with a success message displayed.
This section provides a detailed explanation of the technical elements of the workflow portlet. Since the default implementation relies heavily on the capabilities of jBPM, this section gives a technical overview of jBPM and explains how it integrates into Liferay using their JPDL formatted XMLs. It does not, however, give an in depth view of jBPM. For that, refer to the jBPM user guide (http://docs.jboss.com/jbpm/v3/userguide).
Before the workflow portlet can be used, business processes must be defined. Business processes in jBPM are defined by XML documents known as process definitions which are written in jBPM Process Definition Language (JPDL). These XMLs specify entities such as the process roles (known as swimlanes), the various states in the process (known as nodes), the tasks associated with each node, the roles associated with each task, the transitions from one node to the next, the variables associated with each task’s form, the external actions executed on entry or exit of a node, and many others. For an in depth understanding of process definitions and JPDL, refer to JBoss’ jBPM user guide at http://docs.jboss.com/jbpm/v3/userguide/jpdl.html.
There are three sample process definition XMLs that are packaged with the portlet. They can be found in jbpm-web.war/WEB-INF/definitions. An explanation of each is included in section 2.4. In addition, section 2.4 includes a “Notes” section that gives pointers on Liferay specific implementations of JPDL.
In JPDL, there are process roles called swimlanes. Swimlanes can be associated with Liferay users, groups, and roles via the IdentityAssignmentHandler class.
<swimlane name="approver">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>user</type>
<companyId>liferay.com</companyId>
<id>liferay.com.1</id>
</assignment>
</swimlane>In the XML above, the “approver” swimlane is associated with the Liferay user that has a User ID of “liferay.com.1” and belongs to a Company ID of “liferay.com.” You can also associate a Liferay user with a swimlane by email address as shown in the following XML snippet.
<swimlane name="shipper">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>user</type>
<companyId>liferay.com</companyId>
<name>test.lax.2@liferay.com</name>
</assignment>
</swimlane>
In the XML above, the “shipper” swimlane is associated with the Liferay user that has an email address of “test.lax.2@liferay.com” and belongs to a Company ID of “liferay.com.”
<swimlane name="salesman">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>group</type>
<companyId>liferay.com</companyId>
<id>3</id>
</assignment>
</swimlane>In the XML above, the “salesman” swimlane is associated with any Liferay user that belongs to a Group with the Group ID of “3” (which defaults to the “Support” community) and Company ID of “liferay.com.” In other words, the salesman swimlane is assigned to the pool of “Support” users. If one of these users were to manage a salesman task, he/she would automatically be assigned to all other salesman tasks in the workflow.
<swimlane name="accountant">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>group</type>
<companyId>liferay.com</companyId>
<name>Support</name>
</assignment>
</swimlane>
The XML above shows an alternative way to associate the “accountant” swimlane with the Support community using the actual community’s name. Since community names must be unique per Company ID, this format accomplishes the same results as the previous XML.
<swimlane name="user_admin">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>role</type>
<companyId>liferay.com</companyId>
<id>1001</id>
</assignment>
</swimlane>
<swimlane name="user_interviewer">
<assignment class="com.liferay.jbpm.handler.IdentityAssignmentHandler" config-type="field">
<type>role</type>
<companyId>liferay.com</companyId>
<name>User Interviewer</name>
</assignment>
</swimlane>
The two XML snippets above are very similar to the Group XML snippets. Both associate their respective swimlanes with a role, but the first XML does so using the Role ID and the second XML does so using the role’s unique name.
Currently, jBPM does not have support for variable data types. However, data types have been dealt with in the workflow portlet by incorporating them into the names of the controller variables. The table below shows the data types supported by the portlet and the syntax for the variable names:
| Data Type | Syntax | Description |
| Checkbox | checkbox:name:checkedValue | name = the caption next to the checkbox checkedValue = the value assigned to the variable if the checkbox is checked |
| Date | date:name | name = the caption next to the date selector object |
| email:name | name = the caption next to the text input field | |
| Number | number:name | name = the caption next to the text input field |
| Password | password:name | name = the caption next to the text input field |
| Phone | phone:name | name = the caption next to the text input field |
| Radio Button | radio:name:option1,option2,…* | name = the caption next to the radio buttons option1,option2,…* = a comma-delimited list of options that represent the different radio button options |
| Select Box | select:name:option1,option2,…* | name = the caption next to the select box option1,option2,…* = a comma-delimited list of options that represent the different options in the select drop-down |
| Text | text:name | name = the caption next to the text input field |
| Textarea | textarea:name | name = the caption next to the textarea input field |
Note that for all name and option values, the values should be entered in the XML in lowercase with hyphens used between words. For example:
radio:are-you-hungry:yes,no,a-little-bit
In addition, you should register the corresponding display values in the Language.properties file. For example:
are-you-hungry=Are you hungry? yes=Yes no=No a-little-bit=A little bit
This will ensure that the values are displayed correctly in the portlet to the user. By default, all variables are readable and writable by the user. Therefore, they can be defined as follows:
<variable name="textarea:comments" />
However, if variables should only be readable or writable, or if variables are required, these must be specified in the variable definition:
<variable name="text:name" access="read,write,required" /> <variable name="date:birthday" access="read" />
Variables of data type Date, Number, Email, and Phone are validated in the service call. Also, required fields are validated to ensure a value of some kind was submitted. If invalid values are submitted, the user is returned to the original form and error messages are displayed next to the invalid input fields. Refer to the sample definition jbpm-web.war/WEB-INF/definitions/datatypes_definition.xml for examples of all data types in use in a single form.
The best way to understand JPDL is to look over the 3 sample PAR files included with the workflow portlet. They can be found in jbpm-web.war/WEB-INF/definitions/. Below is a quick summary of each:
datatypes_definition.xml – a good guide to follow to understand how to use each of the data types described in section 2.3
holiday_definition.xml – a simple workflow that allows an employee to make a holiday request with a start and end date, and then a manager can either approve, reject, or send the request back for review
websale_definition.xml – a more complex workflow that emulates an online auction site in which control of the workflow passes through various roles. It is the most complicated of the 3 workflows, but it demonstrates almost all of the BPM features offered by jBPM
Notes:
The JPDL definition XMLs can be created through a graphical design tool offered by JBoss, but that is beyond the scope of this document (see http://docs.jboss.com/jbpm/v3/gpd/ for a detailed explanation) and is also beyond the scope of the portal.
For nodes that have tasks associated with them, each of the variables in the controller will be converted to a form element that the user must update.
For nodes that have tasks associated with them, each of the transitions out of the node is represented as a button in the task’s form. The transition’s name attribute should always be in lowercase with hyphens between words and registered in Language.properties. The display value is used as the button’s name.
Many of the action handler classes found in the com.liferay.jbpm.handler package are just place holders that output relevant text to the console. Conceivably, these classes could perform operations such as sending out emails, initiating batch processes, updating legacy systems...etc.
The websale workflow demonstrates the following jBPM concepts, all of which are discussed in further detail in the jBPM user guide (http://docs.jboss.com/jbpm/v3/userguide/):
Events
Beanshell scripting
Swimlanes
Tasks
Assigment (User/Pool)
Controllers
Variables
Timers
Node Types
State
Task
Fork
Join
Decision
Transitions
Actions
If you have warning messages turned on for your server, in your console you may see some variant of the following message output several times when jBPM is called:
WARN [org.hibernate.engine.StatefulPersistenceContext] Narrowing proxy to class org.jbpm.graph.node.TaskNode - this operation breaks ==
According to the following post on the JBoss forums (from Koen Aers, one of the key contributors to the jBPM project), this is not an error and is not of significance. He explains the reason this warning is thrown: http://www.jboss.com/?module=bb&op=viewtopic&t=73123
Currently, the workflow portlet has no notion of logging other than the ability to review all of the tasks that a user has assigned to them or has completed. However, jBPM provides rather robust logging functionality so administrators/users can monitor every action that has ever been taken in a particular workflow.
The reason logging functionality has not been built out in the current release is because the Liferay development team is not sure what the most effective logging metrics would be to the end user. If you or your organization has logging requirements, please submit them to the Liferay Forums, and we will add logging functionality as we see fit.
Though the workflow portlet’s strength is that it can provide a forms-based data entry application virtually on-the-fly, the forms are very plain and would not be suitable for an organization to roll-out for their end-users. To address this concern, the Liferay development team plans to create stylesheets and templates that can be applied to the forms. The functionality would be very similar to how XSL stylesheets are currently applied to numerous web applications. This enhancement would give organizations flexibility in layout and UI design of their forms.