Liferay
Portal 4 - Portal Administration Guide
Joseph Shum
Alexander Chow
Redmond Mar
Jorge Ferrer
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
Preface
1.
Initial Steps
1.
Accessing the portal
2.
Logging into the portal
2.
Customizing the Personal Area of a User
1.
Adding Portlets
2.
Changing the Theme
3.
User Administration
1.
Overview
1.1.
Administration Portlets
1.2.
User
1.3.
Organizations and Locations
1.4.
User Groups
2.
Enterprise Administration Portlet
2.1.
How to View, Search, Add, and Edit Organizations
2.2.
How to View, Search, Add, and Edit Locations
2.3.
How to View, Search, Add, Edit, Deactivate, Restore, and Delete Users
2.4.
How to Impersonate a User
2.5.
How to View, Search, Add, Edit, Delete, and Assign User Groups
3.
Organization Administration Portlet
3.1.
How to View and Edit your Organization
3.2.
How to View, Search, Add, and Edit Locations that Belong to your Organization
3.3.
How to View, Search, Add, Edit, and Deactivate Users that Belong to Your
Organization
3.4.
How to View, Search, Edit, Delete, and Assign User Groups
4.
Location Administration Portlet
4.1.
How to View and Edit your Location
4.2.
How to View your Organization
4.3.
How to View, Search, Add, Edit, and Deactivate Users
4.4.
How to view, search, add, edit, delete, and assign user groups
4.
Community Administration
1.
Overview
2.
Communities Portlet
2.1.
How to View, Search, Add, Edit, and Delete Communities
2.2.
How to View, Add, Edit, Permission, delete, Manage Look and Feel for, and
Import/Export Pages for a Community
2.3.
How to Assign Users to a Community
2.4.
How to Join and Leave an Open Community
2.5.
How to Control Permissions in a Community
3.
Page Settings link
5.
Security and Permissions
1.
Introduction
2.
Entity Definitions
2.1.
Resources
2.2.
Permissions
2.3.
Roles
2.4.
Users
2.5.
Organizations and Locations
2.6.
Communities
2.7.
User Groups
3.
Administration
3.1.
Creating a Role
3.2.
Assigning Company Permissions to a Role
3.3.
Assigning Community Permissions to a Role
3.4.
Assigning Roles
3.5.
Assigning Individual Portlet Permissions
3.6.
Assigning Default Permissions
3.7.
Assigning Individual Permissions
3.8.
Special Case: Assigning Individual Permissions to Locations
3.9.
Delegating Permissions
6.
Admin Portlet
1.
Server Tab: Shut Down Server
2.
Enterprise Tab: Edit Enterprise's Profile
3.
Portlets Tab: Set Minimum Required Roles for Portlet Access
4.
Users Tab
4.1.
Live Session: View Current Users and End User's Session
4.2.
Authentication: User Account Authentication
4.3.
Default Communities and Roles: Setg Default Community Names and Roles
4.4.
Reserved Users: Reserve User ID and Email
4.5.
Mail Host Names: Add Mail Host Name
4.6.
Emails: Automatically Generated Emails
7.
Message Board Portlet
1.
Adding Category
2.
Adding Thread
3.
Editing Category and Thread
4.
Deleting Category and Thread
5.
Thread Subscription
6.
Configuring Subscription Emails
7.
My Posts
8.
Recent Posts
9.
Statistics
10.
RSS
8.
RSS Portlet
9.
Workflow Portlet
1.
Deploying Workflows
2.
Managing Instances
3.
Managing Tasks
4.
Technical Explanations
4.1.
Process Definitions
4.2.
Integrating with Users, Groups, and Roles
4.3.
Data Types and Error Checking
4.4.
Sample Process Definitions
4.5.
Warning Messages
5.
Future Enhancements
5.1.
Logging
5.2.
Customizable Front-End
5.3.
File Upload Data Type
List of Tables
5.1. Example
Permissions
Preface
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.
Chapter 1. Initial
Steps
Table of Contents
1.
Accessing the portal
2.
Logging into the portal
1. Accessing
the portal
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.
2. Logging
into the portal
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:
Login name or e-mail address
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.
Password
The password of the preconfigured
administrator account is test.
Chapter 2. Customizing
the Personal Area of a User
Table of Contents
1.
Adding Portlets
2.
Changing the Theme
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.
1. Adding
Portlets
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.
2. Changing
the Theme
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
|
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.
|
Chapter 3. User
Administration
Table of Contents
1.
Overview
1.1.
Administration Portlets
1.2.
User
1.3.
Organizations and Locations
1.4.
User Groups
2.
Enterprise Administration Portlet
2.1.
How to View, Search, Add, and Edit Organizations
2.2.
How to View, Search, Add, and Edit Locations
2.3.
How to View, Search, Add, Edit, Deactivate, Restore, and Delete Users
2.4.
How to Impersonate a User
2.5.
How to View, Search, Add, Edit, Delete, and Assign User Groups
3.
Organization Administration Portlet
3.1.
How to View and Edit your Organization
3.2.
How to View, Search, Add, and Edit Locations that Belong to your Organization
3.3.
How to View, Search, Add, Edit, and Deactivate Users that Belong to Your
Organization
3.4.
How to View, Search, Edit, Delete, and Assign User Groups
4.
Location Administration Portlet
4.1.
How to View and Edit your Location
4.2.
How to View your Organization
4.3.
How to View, Search, Add, Edit, and Deactivate Users
4.4.
How to view, search, add, edit, delete, and assign user groups
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.
1. Overview
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.
1.1. 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.
1.2. User
A user is an individual who performs tasks using the
portal.
1.3. Organizations
and Locations
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.
1.4. User
Groups
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.
2. Enterprise
Administration Portlet
Enterprise Administration has the highest level of
administrative functions. It has access to all organizations, locations, and
users.
2.1. How
to View, Search, Add, and Edit Organizations
Organizations are at the top of the group hierarchy
and allows the configuration of permissions to a broad number of users in the
system.
Viewing
Organizations
- 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.
Searching
Organizations
- 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.
Adding
Organizations
- 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.
Editing
Organizations
- Click
on the Organizations tab in the Enterprise Admin Portlet.
- Locate
organization you want to edit. Click the Edit icon ()
to the right of the organization.
- Type
changes in the Name input field. Select from the Country, Status,
and Region menus to make changes.
- Click
Save.
2.2. How
to View, Search, Add, and Edit Locations
Locations can give you broad permissioning and
grouping within an organization.
Viewing
Locations
You can view a list of all locations or you can view
a list of locations that belong to a specific organization.
Viewing All
Locations
- 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.
Viewing
Locations that Belong to a Specific Organization
- Click
on the Organizations tab in the Enterprise Admin Portlet.
- Click
on the View Locations ()
icon located to the right of an organization. A screen will appear showing
all organizations that belong to a specific organization.
Searching
Locations
- 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.
Adding
Locations
- 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.
|
Editing
Locations
- 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.
2.3. How
to View, Search, Add, Edit, Deactivate, Restore, and Delete Users
Viewing
Users
Viewing All
Users
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.
Viewing
Users that Belong to a Specific Organization
- Click
on the Organizations tab.
- Click
the View User icon ()
located to the right of an organization.
- Click
on a user to view.
Viewing
Users that Belong to a Specific Location
- Click
on the Locations tab.
- Click
the View User icon ()
located to the right of a location.
- Click
on a user to view.
Searching
Users
- 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.
Adding Users
- 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.
Editing
Users
- 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.
Deactivating
Users
- 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.
Restoring
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.
Deleting
Users
- 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.
2.4. How
to Impersonate a 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.
2.5. How
to View, Search, Add, Edit, Delete, and Assign User Groups
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.
Viewing User
Groups
- 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.
Searching
User Groups
- 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.
Adding User
Groups
- 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.
Editing User
Groups
- 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.
Deleting
User Groups
- 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.
Assigning
Users to 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.
3. Organization
Administration Portlet
Various functions can be performed to your
organization and to location and users that belong to your organization.
3.1. How
to View and Edit your Organization
Viewing 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.
Editing your
Organization
- 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.
3.2. How
to View, Search, Add, and Edit Locations that Belong to your Organization
Viewing
Locations
- 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.
Searching
Locations
- 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.
Adding
Locations
- 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.
Editing
Locations
- 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.
3.3. How
to View, Search, Add, Edit, and Deactivate Users that Belong to Your
Organization
Viewing
Users
You can view all users that belong to your
organization or view users that belong to a specific location.
Viewing All
Users
- 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.
Viewing
users that belong to a specific location
- Click
on the Locations tab.
- Click
on the View Users icon ()
located to the right of a location.
- Click
on a user to view.
Searching
Users
- 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.
Adding User
- 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.
Editing User
- 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.
Deactivate
User
- 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.
3.4. How
to View, Search, Edit, Delete, and Assign User Groups
Viewing User
Groups
- 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.
Searching
User Groups
- 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.
Editing User
Groups
- 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.
Deleting
User Groups
- 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.
Assigning
Users to 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.
4. Location
Administration Portlet
Various functions can be performed to your location
and users that belong to a location.
4.1. How
to View and Edit your Location
Viewing your
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.
Editing your
location
- To
edit your location, click on the Location tab in the Location Admin
Portlet.
- Click
the Edit icon ()
located to the right of the location listing.
- Type
changes in the Name input field. Select from the Country, Region,
and Status menus to make changes.
- Click
Save.
4.2. How
to View your Organization
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.
4.3. How
to View, Search, Add, Edit, and Deactivate Users
Viewing
Users
- 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.
Searching
Users
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.
Adding Users
- 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.
Editing
Users
- 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.
Deactivating
Users
- 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.
4.4. How
to view, search, add, edit, delete, and assign user groups
See section 2.4, but replace all references to the
Enterprise Admin Portlet with Location Admin Portlet.
Chapter 4. Community
Administration
Table of Contents
1.
Overview
2.
Communities Portlet
2.1.
How to View, Search, Add, Edit, and Delete Communities
2.2.
How to View, Add, Edit, Permission, delete, Manage Look and Feel for, and
Import/Export Pages for a Community
2.3.
How to Assign Users to a Community
2.4.
How to Join and Leave an Open Community
2.5.
How to Control Permissions in a Community
3.
Page Settings link
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.
1. Overview
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.
2. Communities
Portlet
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
2.1. How
to View, Search, Add, Edit, and Delete Communities
Viewing
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.
Searching
Communities
- To
search for communities on either the Current or Available tab, type a
community name in the "Name" input field.
- Click
Search.
Adding
Communities
- 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.
Editing
Communities
- 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.
Deleting
Communities
- Click
on the Delete icon ()
to the right of the community.
- A
screen will appear asking if you want to delete the selected community.
Click OK to delete. Click Cancel if you do not want to
delete the selected community.
2.2. How
to View, Add, Edit, Permission, delete, Manage Look and Feel for, and
Import/Export Pages for a Community
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.
Viewing
Pages
- 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.
Adding Pages
- 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.
Editing
Pages
- 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.
Permission
Pages
- An
exhaustive discussion of page permissions is provided in Chapter 3. In
particular, see section 3.9.3
Deleting
Pages
- 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.
Manage Look
and Feel for Pages
- 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.
Import/Export
Pages
- 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.
2.3. How
to Assign Users to a Community
Users can either be assigned directly or indirectly
to a community. Both methods of assignment will be discussed below.
Assigning
Users Directly to a Community
- 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.
Assigning
Users Indirectly to a Community
- 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.
2.4. How
to Join and Leave an Open Community
Joining an
Open Community
- 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.
Leaving an
Open Community
- 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.
2.5. How
to Control Permissions in a Community
See Chapter 3 for an exhaustive explanation of how to
use the new security and permissions model in Liferay 4.0. In particular, see
sections 3.9.2 and 3.9.3 for explanations of
how to control community and page permissions.
3. Page
Settings link
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
Chapter 5. Security
and Permissions
Table of Contents
1.
Introduction
2.
Entity Definitions
2.1.
Resources
2.2.
Permissions
2.3.
Roles
2.4.
Users
2.5.
Organizations and Locations
2.6.
Communities
2.7.
User Groups
3.
Administration
3.1.
Creating a Role
3.2.
Assigning Company Permissions to a Role
3.3.
Assigning Community Permissions to a Role
3.4.
Assigning Roles
3.5.
Assigning Individual Portlet Permissions
3.6.
Assigning Default Permissions
3.7.
Assigning Individual Permissions
3.8.
Special Case: Assigning Individual Permissions to Locations
3.9.
Delegating Permissions
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.
1. Introduction
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.
2. Entity
Definitions
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.
2.1. Resources
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.
2.2. Permissions
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.
2.3. Roles
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.
2.4. Users
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
2.5. Organizations
and Locations
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.
2.6. Communities
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.
2.7. User
Groups
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.
3. Administration
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.
3.1. Creating
a Role
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.
3.2. Assigning
Company Permissions to a Role
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.
3.3. Assigning
Community Permissions to a Role
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.
3.4. Assigning
Roles
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.
3.5. Assigning
Individual Portlet Permissions
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.
3.6. Assigning
Default Permissions
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.
3.7. Assigning
Individual 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!
3.8. Special
Case: Assigning Individual Permissions to Locations
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.).
3.9. Delegating
Permissions
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.
Portal
Permissions
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.
Community
Permissions
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.
Page
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.
Portlet
Permissions
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.
Enterprise
Admin Permissions
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.
Role
Permissions
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.
Personal
Community Permissions
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.
Chapter 6. Admin
Portlet
Table of Contents
1.
Server Tab: Shut Down Server
2.
Enterprise Tab: Edit Enterprise's Profile
3.
Portlets Tab: Set Minimum Required Roles for Portlet Access
4.
Users Tab
4.1.
Live Session: View Current Users and End User's Session
4.2.
Authentication: User Account Authentication
4.3.
Default Communities and Roles: Setg Default Community Names and Roles
4.4.
Reserved Users: Reserve User ID and Email
4.5.
Mail Host Names: Add Mail Host Name
4.6.
Emails: Automatically Generated Emails
The functionalites of each tab in the Admin Portlet,
except for the Auto Deploy tab, will be explained in this section.
1. Server
Tab: Shut Down Server
- 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.
2. Enterprise
Tab: Edit Enterprise's Profile
- 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.
3. Portlets
Tab: Set Minimum Required Roles for Portlet Access
- 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.
4. Users
Tab
Under the User tab are six sub-tabs:
4.1. Live
Session: View Current Users and End User's Session
- 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.
4.2. Authentication:
User Account Authentication
- 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.
4.3. Default
Communities and Roles: Setg Default Community Names and Roles
- 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.
4.4. Reserved
Users: Reserve User ID and Email
- 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.
4.5. Mail
Host Names: Add Mail Host Name
- Additional
mail host names besides liferay.com can be entered here.
- Click
Save after making any changes.
4.6. Emails:
Automatically Generated Emails
- 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.
Chapter 7. Message
Board Portlet
Table of Contents
1.
Adding Category
2.
Adding Thread
3.
Editing Category and Thread
4.
Deleting Category and Thread
5.
Thread Subscription
6.
Configuring Subscription Emails
7.
My Posts
8.
Recent Posts
9.
Statistics
10.
RSS
1. Adding
Category
- 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.
2. Adding
Thread
- Click
Post New Thread.
- Enter
a name and description.
- Save.
3. Editing
Category and Thread
- To
edit a category or thread, click on the Edit ()
button located next to the category or thread you want to edit.
4. Deleting
Category and Thread
- To
delete a category or thread, click on the Delete ()
button next to the category or thread you want to delete.
5. Thread
Subscription
- To
be notified by email when a new message has been posted or updated, click Subscribe
().
- To
unsubscribe, click Unsubscribe ().
6. Configuring
Subscription Emails
- 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.
|
7. My
Posts
- Click
on the My Posts tab to view a list of your postings.
8. Recent
Posts
- Click
the Recent Posts tab to see a list of recent postings.
9. Statistics
- Click
the Statistics to see posting statistics.
- Click
Top Posters to see a list of most active users.
10. RSS
- To
subscribe to a RSS feed that will be added to browser's bookmark, choose a
topic you want to subscribe to and click RSS ().
- Follow
the browser's instructions to subscribe.
Chapter 8. RSS
Portlet
- 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.
Chapter 9. Workflow
Portlet
Table of Contents
1.
Deploying Workflows
2.
Managing Instances
3.
Managing Tasks
4.
Technical Explanations
4.1.
Process Definitions
4.2.
Integrating with Users, Groups, and Roles
4.3.
Data Types and Error Checking
4.4.
Sample Process Definitions
4.5.
Warning Messages
5.
Future Enhancements
5.1.
Logging
5.2.
Customizable Front-End
5.3.
File Upload Data Type
1. Deploying
Workflows
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.
2. Managing
Instances
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.
|
3. Managing
Tasks
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.
4. Technical
Explanations
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).
4.1. Process
Definitions
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.
4.2. Integrating
with Users, Groups, and Roles
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.
4.3. Data
Types and Error Checking
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
|
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.
4.4. Sample
Process Definitions
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
4.5. Warning
Messages
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
5. Future
Enhancements
5.1. Logging
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.
5.2. Customizable
Front-End
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.
5.3. File
Upload Data Type
There have already been several requests to add a
file data type to provide a means for users to upload files that are associated
with workflow tasks. This will definitely be a future enhancement.