Liferay - Wiki

stockingssoyaInternet και Εφαρμογές Web

7 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

92 εμφανίσεις

Liferay
-

Wiki

Plugins SDK

Tags:
customization
development

Table of
Contents

[
-
]



1 Introduction



2 Preparation



3 Working with plugins



3.1 Common tasks



3.2 Creating a new theme



3.3 Creating a new portlet



4 Example plugins

Introduction

The Liferay Plugins SDK is a development environment that helps in the development of all
types
of plugins for Liferay including:



Portlets



Themes



Layout templates

This development environment is based on the popular
Apache Ant

tool so that it can be
integrated

with all the popular IDEs or used directly from the command line.

Preparation

The preparation can be done in a few minutes. Follow these steps:

1.

Download the Plugins SDK from
http://www
.liferay.com/web/guest/downloads/additional

2.

Unzip the ZIP file to your destination of choice. I'll refer to it from now on as
$PLUGINS_SDK

3.

Create a file named $PLUGINS_SDK/build.${user.name}.properties where
${user.name} is the name of the user in your sys
tem. In that file you can overwrite the
values of any of the properties in the $PLUGINS_SDK/build.properties file. Some
common properties that are overridden (with example values) are:

1.

app.server.dir=/my
-
dir/appservers/liferay
-
portal
-
tomcat
-
jdk5
-
trunk

2.

auto
.deploy.dir=${user.home}/liferay/deploy

3.

app.server.lib.portal.dir=/my
-
dir/liferay/trunk/portal
-
web/docroot/WEB
-
INF/lib

4.

app.server.portal.dir=/my
-
dir/liferay/trunk/portal
-
web/docroot

5.

javac.compiler=modern

4.

Install
Apache

Ant
. If you want to be able and make sure that ANT_HOME/bin is in your
path to be able to

Working with plugins

Common tasks

The most common tasks can be performed executing ant tasks. Those tasks can be executed
either from the root directory to apply
to all the plugins, from the themes|portlets|layouttpl
directories to apply only to the themes, portlets or layout templates, or within the directory of a
single plugin to apply only to it.

Here are the most common tasks along with the associated ant targe
t



Compile the sources (applicable only to portlets):


ant compile



Create a WAR file of the plugin


ant war



Deploy the plugin (to the path confibured in the auto.deploy.dir property of the
$PLUGINS_SDK/build.${user.name}.properties file)


ant deploy

Creating a new theme



In the $PLUGINS_SDK/themes folder run:


create newtheme "My New Theme"



Navigate to the newly created $PLUGINS_SDK/themes/newtheme/_diffs and add some
customizations to the default theme.



Issue 'ant all' in the $PLUGINS_SDK/themes fol
der to build and deploy.



Log in into Liferay and check out your new creation.

Creating a new portlet



In the $PLUGINS_SDK/portlets folder run:


create newportlet "My New Portlet"

or in Linux:


./create.sh newportlet "My New Portlet"

(Where newportlet is
the name of the folder for your portlet and "My New Portlet" the display
name)



Issue 'ant all' in the $PLUGINS_SDK/portlets folder to build and deploy



Log in into Liferay and check out your new creation

Example plugins

Liferay uses the Plugins SDK to develop the plugins that come with Liferay. This includes a lot
of examples that you may want to use as a basis for your development. You can
down
load them
from Sourceforge

and also browse and download the code in Liferay's
Subversion repository



Using Liferay's Permission System from a
portlet

Tags:
development
liferay v4.3
liferay v4.4

Table of Contents

[
-
]



1 Important concepts



2 Learning with a real world example



2.1 Int
roducing the example: student scores management



2.2 Step 1) Defining the types of resources



2.3 Step 2) Create the resources that will be controlled by the permission system



2.4 Step 3) Add permission checks whenever a user is performing a restricted operation



2.5 Test it



3 Getting more out of the permission system



3.1 Utility classes to check permission



3.2 Default permissions



3.3 Disabling certain permissions for guest



4 Learn more

Liferay's permission system is a very flexible mechanism to define the actions a given user can
perform within the general context of the portal, or

within a given portlet and its data. Portal and
portlet developers break down the operations which can be performed withing the portlet, and/or
on the data they create, into distinct "actions". The act of granting the ability to perform a given
action to
an individual user, role, user group, etc. is of course the act of granting that permission.
In this way, portal/portlet developers are not tied to named roles, user group, or any other
authorization model in particular, all they need to care about is clea
rly defining the different
types of operations required to suite the business logic of their applications.

Once the actions have been identified and configured, the system administrator is free to grant
permissions to perform those actions to users, groups
, communities, etc, either directly or
through roles, using the portal's administration tools or specifically within portlet's
configurations UIs.

The purpose of this article is to explain how a portlet developer can use this service during
development to
give the portal administrator the same level of control over permissions that she
has over the bundled Liferay portlets.

Important concepts

The main concepts behind Liferay's permission system are those of
actions

and
resources
.
Examples of actions would be: VIEW, UPDATE, MOVE, etc. Examples of resources could be:
RSS portlet hF5f, the message board post with id 5, an event of the community X, a wiki page of
the portal. Note that these four examples each have a different degree
of specificity. That's one of
the reasons for the flexibility of the system and we'll get back to it in detail later.

Permissions in Liferay are defined as actions on a given resource. For example
view the
message board post with id 5
,
edit events of commu
nity X
, etc. Permissions can be assigned
directly to users, although it's recommended to do it through roles (which can be seen as a group
of permissions), user groups, organizations or communities.

In order to use the permission system, a portlet develope
r must follow these steps:

1.

Define the types of resources of the portlet and the actions that can be performed on each.
This is done in an XML file.

2.

If the portlet defines a domain model, create the resource (or resources) which can be
controlled through th
e permission system. This is done through a API call. An example of
this are Message Board Threads.

3.

Add permission checks whenever a user is performing a defined
action
. This is also done
through a API call.

One important point related specifically to the
portlet

resource itself, is that, by default, and
regardless of the actions specified by the developers, the portlet will implicitly have two
actions

defined on it. These are CONFIGURATION and VIEW.

:;CONFIGURATION : involves, at the least, performing main
tenance operations that are
provided through portal functionality such as adjusting the
look
-
and
-
feel

of the portlet, changing
it's title, and assign permissions on the portlet. :;VIEW : involves two facets, the first is whether
to allow a user, who has th
e ability to see and use the
Add Content/Application/Portlet

menu,
to see a listing of the portlet, and secondly, if the portlet is already on a page/layout, whether that
user can see the portlet or either a message indicating they don't have permission, o
r nothing at
all.

In some cases it might be desirable to do some further steps to add more functionality. But we'll
leave that for a later section.

Learning with a real world example

Introducing the example: student scores management

The example that we
are going to use is that of a portlet that allows a teacher to record the scores
of his students. We'll assume that the teacher and the students each have individual portal
accounts already. The system will have two types of persistent entities: Test and S
core (of a
student in a test).

Step 1) Defining the types of resources

The definition of the portlet resources is done in an XML file that should be placed in the
classpath. Liferay's convention is to place it in the portal
-
impl/classes/resource
-
actions/
directory
and give the file the 'semantic' name of the portlet (such as messageboards.xml). (In the ext
environment it change portal
-
impl for ext
-
impl in the previous path).

We'll name the file studentscores.xml and create it with the following content:


<resource
-
action
-
mapping>


<portlet
-
resource>


<portlet
-
name>studentscores</portlet
-
name>


<supports>


<action
-
key>ADD_TEST</action
-
key>


<action
-
key>CONFIGURATION</action
-
key>


<action
-
key>VIEW</action
-
key
>


</supports>


<community
-
defaults>


<action
-
key>VIEW</action
-
key>


</community
-
defaults>


<guest
-
defaults>


<action
-
key>VIEW</action
-
key>


</guest
-
defaults>


</portlet
-
resource>


<
model
-
resource>


<model
-
name>com.liferay.portlet.studentscores.model.SCTest</model
-
name>


<portlet
-
ref>


<portlet
-
name>studentscores</portlet
-
name>


</portlet
-
ref>


<supports>


<action
-
key>ADD_SCORE<
/action
-
key>


<action
-
key>DELETE</action
-
key>


<action
-
key>UPDATE</action
-
key>


<action
-
key>VIEW</action
-
key>


</supports>


<community
-
defaults />


<guest
-
defaults />


</model
-
resource>


<model
-
re
source>


<model
-
name>com.liferay.portlet.studentscores.model.SCScore</model
-
name>


<portlet
-
ref>


<portlet
-
name>studentscores</portlet
-
name>


</portlet
-
ref>


<supports>


<action
-
key>DELETE</action
-
key>


<action
-
key>UPDATE</action
-
key>


<action
-
key>VIEW</action
-
key>


</supports>


<community
-
defaults />


<guest
-
defaults />


</model
-
resource>


</resource
-
action
-
mapping>

Let's review the file from beginning to e
nd. The first thing to note is that it defines 3 resources.

The first one is a resource for the portlet itself. By defining it, the administrator will be able to
configure which users can perform each operation on the portlet when it's placed in a page. T
his
resource supports 3 actions: :;ADD_TEST: the user with the permission to perform this action is
allowed to add a new test through the portlet. :;CONFIGURATION: the user with this
permission can alter the
look
-
and
-
feel
, change the title, and assign perm
issions on the portlet.
:;VIEW: the user with the permission to perform this action is allowed to view the contents of
the portlet, and, if they are a
layout manager

(see definition bellow), see it in the
Add
Content/Application/Portlet

menu.

The second
resource represents a test created through the portlet. It supports the following
actions: :;ADD_SCORE: Add the score of a student for this test :;DELETE: Delete the test
:;UPDATE: Update the test :;VIEW: View the test

The score also has an associated type

of resource with the following actions: :;DELETE: Delete
the score :;UPDATE: Update the score :;VIEW: View the score

Once this file is finished we are ready to start the development part of our assignment.

Step 2) Create the resources that will be control
led by the permission system

Whenever a new test or a new score is added through our portlet we need to inform the
permission system of it so that it can create a set of resources associated with them. This is
achieved through a call to the ResourceLocalS
ervice. This service can be invoked through the
ResourceLocalServiceUtil class or by receiving an instance through dependency injection. In this
example we'll assume the latter. So after our custom code has created a new test we invoke:


resourceLocalServi
ce.addResources(


test.getCompanyId(), test.getGroupId(), test.getUserId(),


SCTest.class.getName(), test.getTestId(),


false, addCommunityPermissions, addGuestPermissions);

There are several things to note here:

1.

The test class contains a
companyId field. This is necessary to support Liferay's multi
-
instance functionality

2.

The test class contains a groupId field. This means that our tests will be scoped by group
(that is by community or organization). If we had decided to have a unique set o
f tests for
the whole portal instance we should have specified 0.

3.

The third parameter, userId, is the userId of the user that created the resource. The
permission system will automatically give all permissions to this user.

4.

The fourth parameter, name iden
tifies the type of resource and by convention it is
recommended to use the class name that represents this type of entries.

5.

The fifth parameter, primKey, must be a unique id of the current entry

6.

The sixth parameter, portletActions, must be false because th
is is not an entity that
represents a portlet. You will hardly ever need to set this parameter to true.

7.

The seventh and eight parameter determine if a set of permissions should be given to the
owners of the group to which the test belongs and to anonymous
users or not. That set of
permissions is configured through the XML file. We left both sets empty so it doesn't
make any difference to us. You can just give them a value of false.

It's interesting to understand what happens when this method is invoked. In
short it will create
several resources associated with the test we just created. Let's see why more than one resource
and the purpose of each of them:

1) A resource with scope individual which represents one and only one SCTest (the one we just
created). T
his resource will allow the administrator to set up permissions to operate on this
specific SCTest. 2) A resource with scope group. This is done only once for the first SCTest
created within this group. All others will share the same resource. This resourc
e will allow the
administrator to set a permission that applies to all SCTest within a given community or
organization. Usually this is done through regular roles. 3) A resource with scope
group_template. It's very similar to the previous but it's used sli
ghtly different by administrator.
This resource allows a community or organization role to include a permission to do an action on
all SCTest within a given community or organization. Which community or organization will be
determined when the role is assi
gned to a user. 4) A resource with scope company. This is only
done for the first template created within this company. This resource allows an administrator to
set a permission that applies to all SCTest in the whole portal instance (called Enterprise in
the
permissions administration UI).

Whenever permissions are checked for a SCTest entity it checks first if it has permission in the
associated individual scoped resource, then in the group scoped resource and then in the
company scoped resource.

We are re
ady to test it. But first lets sure the system is always in good shape and does not contain
resources of SCTest that do not exist any more. To achieve that when a SCTest is deleted we
should also delete its associated resources. Actually we only have to de
lete the resource with
scope individual since all other are shared with other tests. So we invoke:


resourceLocalService.deleteResource(


message.getCompanyId(), SCTest.class.getName(),


ResourceImpl.SCOPE_INDIVIDUAL, test.getTestId());

For each sc
ore that we add or delete we should do the same thing that we've just shown for tests.

Step 3) Add permission checks whenever a user is performing a restricted
operation

Our third step will be to check whether a user has permission to do a certain action
when he tries
to do it. First we'll check whether the user has permission to add a new test.

The API to check permission is centralized in a class called PermissionChecker (for the curious,
actually that's an interface, and the actual class provided by
default to implement the interface is
PermissionCheckerImpl). Liferay creates an instance of that class for every request and reuses it
for all checks for permissions to ensure maximum eficiency. To obtain the current permission
checker the easiest way is
to use Liferay's taglib theme:defineObjects:


<theme:defineObjects/>

After invoking this tag a JSP variable called permissionChecker will be available. If you don't
want to use the tag you can access the permission checker using the following code (add the

imports necessary to make it run):


<%


ThemeDisplay themeDisplay =
(ThemeDisplay)request.getAttribute(WebKeys.THEME_DISPLAY);


PermissionChecker permissionChecker = themeDisplay.getPermissionChecker();


%>

Once we have the PermissionChecker instance we

can invoke its method contains to find out if
the user has the desired permission:


permissionChecker.hasPermission(


layout.getGroupId(), "studentscores", testId, "ADD_SCORE");

As a result of this invocation our code should throw an Exception if
the user is not allowed to do
the requested action and the UI should catch that exception and show a message to the user.
Liferay's portlets use PrincipalException for that task, so feel free to reuse it.

Important Note
: by passing the groupId to permissionChecker we are implicitly telling the
permission system that this action is performed within the context of the current group. Because
of that an administrator of the current group will always have permission to perfor
m that action
even if it wasn't assigned explicitly. If you don't want that use 0 as the groupId. Note that in that
case permissions to perform this action within an specific community will have no effect.

The same check should also be applied in the UI to

show or hide the actions that are presented to
a user based on his privileges. For example:


<c:if test="<%= permissionChecker.hasPermission(layout.getGroupId(),
"studentscores", testId, "ADD_SCORE");


%>">


<a href="<%= addScoreURL %>" >Add score<a/>


</c:if>

Test it

Once we've added the appropriate checks all around our portlets we are ready to test. The easiest
way to do it is by creating custom roles that give different permissions within our portlets.

To do that go to the Enterprise Admin portlet
and create one or more regular roles. For each role
chosse the "Define permissions" action. Then click the "Add portlet action" and look for your
portlet. When you click on it you'll see a form with all the actions that can be performed on each
of the reso
urces defined in the XML file above. (Note: for versions of Liferay Portal prior to 4.4
this screen is divided, you'll have to navigate using the links to configure each resource)

Note that for each action you can just leave the combo next to it blank (whi
ch means don't assign
the permission), set it to enterprise (which means allow it for all resources within the portal) or
set it to community (which means allow it for specific communities). For the latter option you'll
have to choose one or more communiti
es using the provided selection pop
-
up.

Once the role or roles have been defined assign it to a user and go to your portlet to test out the
different permissions.

Getting more out of the permission system

Utility classes to check permission

The
PermissionChecker API is pretty low level. Usually portlet developers develop classes
around it to ease checking permissions. Liferay Portal comes with several classes available that
can be used and others that can be used as an example to build your own.
Here are some
significant ones:

:;PortletPermissionUtil: useful for checking "portlet" level actions. In our case that would be
VIEW, CONFIGURATION and ADD_TEST. Note that this class grants a user with UPDATE
permission in the page where the portlet is, wi
th the permission to do any action, by default. In
order to prevent this in prior versions just don't use this class and use permissionChecker
directly. Beginning with 4.4, this can be disabled by using the 'strict' parameter set to true;
although, this do
es not prevent higher level
layout managers

(Community
Administrators/Owners, like Power Users) from performing any action on the portlet. In order to
do
that

you must explicitly indicate what actions these users can perform by adding a
layout
-
manager

elem
ent to the portlet resource configuration: e.g. This limits the
layout manager

to
only VIEW action by default.


<layout
-
manager>


<action
-
key>VIEW</action
-
key>


</layout
-
manager>

:: Of course further permissions can be granted to these users through explicit assignment. But
remember, that by leaving this out, the
layout manager

will be able to perform
ALL

actions
available on the portlet. :;PortalPermissionUtil: useful for checking

"portal" level actions. This is
useful when we have some actions that do not really belong to a given portlet nor want to be
assigned for a specific community. An example would be a permission to 'Add Users' to the
portal. :;BookmarksFolderPermission: thi
s is a class created explicitly to check permissions to
operate with folders of the Bookmarks portlet. You probably won't be using it (unless you are
interacting with that portlet). But you may want to take a look at its code to create a similar one
for yo
ur own data. In our example we could create a SCTestPermission class and a
SCScorePermission class.

Default permissions

Often we want our data entries to have certain default permissions when they are created. That
can be achieved by specifying those acti
ons in the XML file. Two sets can be specified, one for
the default permissions for community members and another for guest users:


<community
-
defaults>


<action
-
key>ADD_FILE</action
-
key>


<action
-
key>ADD_MESSAGE</action
-
key>



<action
-
key>REPLY_TO_MESSAGE</action
-
key>


<action
-
key>SUBSCRIBE</action
-
key>


<action
-
key>VIEW</action
-
key>


</community
-
defaults>


<guest
-
defaults>


<action
-
key>VIEW</action
-
key>


<
/guest
-
defaults>

Note that for this defaults to be applied you have to give a value of true to the
addCommunityPermissions and addGuestPermissions parameters when creating the associated
resources:


resourceLocalService.addResources(


test.getCompanyId(), test.getGroupId(), test.getUserId(),


SCTest.class.getName(), test.getTestId(),


false, addCommunityPermissions, addGuestPermissions);

Disabling certain permissions for guest

Some permissions that are considered dangerous can
be disabled for guests. By doing this not
even the administrator will be able to assign the permissions to users that are not logged in:


<guest
-
unsupported>


<action
-
key>ADD_FILE</action
-
key>


<action
-
key>ADD_SUBCATEGORY</acti
on
-
key>


<action
-
key>SUBSCRIBE</action
-
key>


<action
-
key>UPDATE</action
-
key>


<action
-
key>UPDATE_THREAD_PRIORITY</action
-
key>


</guest
-
unsupported>

Learn more

http://www.liferay.com/web/guest/community/wiki/
-
/wiki/Main/Permissioning+Explained

Definitions : :;layout manager: Any user who has editorial rights to the c
urrent page/layout.
These include Community Administrators, Community Owners, Power Users (only when in their
private Community), or any user who has been granted or has inherited UPDATE permission on
the current page/layout.



Permissioning Explained

Tags:
understanding and improving liferay

Table of Contents

[
-
]



1 Basic entities



1.1 User_



1.2 Organization_



1.3 UserGroup



1
.4 Group_



2 Permissions and Roles



2.1 Resource_



2.2 Permission_



2.3 Role_



2.4 Roles_Permissions



3 Assignment of users to communities and organizations



3.1 Users_Groups



3.2 Users_Orgs



3.3 Users_UserGroups



4 Assignment of roles and permissions



4.1 Users_Permissions



4.2 Users_Roles



4.3 Groups
_Permissions



4.4 Groups_Roles



4.5 Groups_Orgs



4.6 Groups_UserGroups



4.7 OrgGroupPermission

This article explains the inner details of how the permissions system works in Liferay. And it
does so by exami
ning each of the tables (and therefore the entities) and the relationships that are
involved in the security logic. The following ERD diagram shows the relationships among all the
entities that are going to be explained:


Basic entities

Let's start by
examining a few tables I like to call "entity" tables. In other words, they define
entities in the system that can have permissions/roles attached to them.

User_

The most obvious entity is the User. In the simplest terms, permissions is all about asking t
he
question, "Does this user have permission to do this action on this thing?"

Organization_

Users can belong to only one Organization and one Location. The confusing thing about the data
model is that we use the same table to represent both. Basically,
if the parentOrganizationId
column has a
-
1, then it's an Organization, and if it's any other number, it's a Location. The "only
one Organization and one Location" rule is maintained through logic in our code...not through
data integrity. The logic also en
forces that the Organization that a User belongs to must be the
parent of the Location that the user belongs to. Users inherit permissions/roles from the
Organization and Location that they belong to.

UserGroup

Users can belong to any number of UserGroups
. UserGroups are just arbitrary collections of
Users. Again, Users can inherit permissions/roles from UserGroups. For the time being, the
parentUserGroupId column is not being used.

Group_

Group is the old school name for what we currently call Communitie
s. Users can belong to any
number of Communities and inherit permissions/roles from them. Notice that in the Group_
table, there is a className and classPK column. If className and classPK are blank, then the
record is a Community. If className is com.life
ray.portal.model.User, then the record represents
a private user community (only applies to Power Users). If className is
com.liferay.portal.model.Organization, then the record represents an Organization or Location. If
className is com.liferay.portal.mode
l.UserGroup, then the record represents a UserGroup.

The reason for having Group records representing Organizations/Locations and UserGroups is to
have one entry in this table for each entity in the system that represents a set of users. This
simplifies r
elationships of other entities (such as permissions or roles) with these sets of users.

Permissions and Roles

Ok...now let's look at all the tables that actually connect permissions to these entities. But first,
let's review how a permission is defined. Q
uite simply, it's an ACTION acting on a RESOURCE.
Permissions can be assigned directly to a User or inherited through different means. A collection
of permissions is known as a Role. Let's start by looking at the Resource_ table:

Resource_

A resource is a

representation of an object in the portal...anything that you'd want to slap a
permission on. It could be a portlet, a community, a user, a message board topic, a blog
entry...whatever. Let's take a quick look at each of the columns in the Resource_ table
:



resourceId = The unique id of the resource



companyId = The company that this resource belongs to



name

= The "name" of the object that this resource represents. If the object is a portlet,
it's the portletId. If it's a class, it's the fully qualified package name of the class



typeId = For the time being, we're only concerned with permissioning classes, so
this
value will always be "class". However, in the future, we might start permissioning files or
folders, so typeId might take on the values of "file" or "folder".



scope = The possible values are "company" (we refer to it as "Enterprise Scope"),
"group" (w
e refer to it as "Community Scope"), or "individual" (we refer to it as
"Individual Scope"). Why the different naming conventions? Because things change...
The numeric values for scope (as found in the database) can be found in the class
com.liferay.portal
.model.impl.ResourceImpl

Permission_

As stated earlier, a permission is an action acting on a resource. Therefore, the Permission_ table
has an actionId and resourceId column. As expected, the resourceId column references the
resourceId column from the Re
source_ table. However, the actionId column doesn't have a
corresponding Action_ table. All actionIds are defined in the ActionKeys class. Wanna know
how to define new actions for resources? Read
Implementing Permissions

Role_

This is the table where a role is defined. Really, the only important column is the name column
because roles must have unique names.

Roles_Permissions

This is the relational table that links a permission

to a role. Without these links, roles would be
useless...they'd just be empty containers.

Assignment of users to communities and organizations

Users_Groups

This is the relational table that links a User to a Community. You're probably wondering why we
don't have a className and classPK column in this table so we could handle all entities (e.g.,
Communites, Organization/Locations, UserGroups) in one table. Aga
in, too hard to explain, but
trust us...it's better this way.

Users_Orgs

This is the relational table that links a User to an Organization/Location.

Users_UserGroups

This is the relational table that links a User to a UserGroup.

Assignment of roles and p
ermissions

Users_Permissions

This is the relational table that directly links a permission to a user.

Users_Roles

This is the relational table that links a role to a user. The user then inherits all the permissions
linked to that role (via Roles_Permiss
ions).

Groups_Permissions

This is the relational table that links a permission to a Group. Remember earlier in our discussion
how we said a Group_ record could either represent a Community, Organization/Location, or
UserGroup? Well, this is the table that

directly links those permissions to each of these entities.
And then of course, users that belong to these entities would inherit the permissions. Notice there
is no Orgs_Permissions or UserGroups_Permissions tables. Groups_Permissions is enough to
handle

all cases. Maybe now it makes more sense why this is simpler.

Groups_Roles

This is the relational table that links a role to a Group. Just like for Groups_Permissions, a Group
could either refer to a Community, Organization/Location, or UserGroup. Users
that belong to
these "Groups" would then inherit the permissions from the corresponding roles.

Groups_Orgs

This is the relational table that links Organizations/Locations to Communities. In other words, an
admin can assign every User that is part of a par
ticular Organization or Location to a
Community. As a result, any permissions or roles assigned to that Community would now be
inherited by every User in the selected Organization/Location

Groups_UserGroups

Exactly the same reasoning as Groups_Orgs, excep
t for UserGroups

OrgGroupPermission

Here's the odd ball of the bunch. This table is used for "Exclusive Permissions". Basically, a user
has to belong to a particular Location (or Organization since Liferay v4.4) AND a particular
Community to receive this
permission. By the way, though the OrgGroupRole table exists, it is
never used in our code.

Let's see why this option is useful with an example. Within a community there is a message
boards, and the administrator wants to set up a category of the message
boards so that only the
users that belong to a given location can post to it. So he clicks the 'Permissions' icon for that
category and selects the appropriate location. Now ALL users of the location will be able to post,
regardless of whether they are mem
bers of the community or not.

In some circumstances, the administrator may want to restrict this further, saying that the user
must also belong to the organization to post to that category. He can achieve that by setting
"Exclusive Permissions"



Using
Pop
-
up in Liferay

Tags:
development
liferay 5.1
liferay 5.2
liferay popup
pop u
p
pop
-
up

Table of Contents

[
-
]



1 Floating Div Pop
-
Up



2 Window Pop up

When developing portlets in Liferay there are two ways to implement pop
-
ups. We can use a
Floating Div or the traditional new browser Window without the toolba
rs. Each of them has got
their advantages so we will have to decide which one fits us better. For example, if you are using
a pop up with a form, you won't be able to send files attached to the form if you are using a
floating div.

In this article there ar
e some tips to develop both types of pop
-
ups.

Floating Div Pop
-
Up

Liferay provides a class called
Liferay.PopUp

to implement this type of pop ups. Here is how
this type of pop up would look like:


One advantage of this type of pop up is that they are invisible to pop up blockers (although that
could change as they get smarter). This javascript code will make an asynchronous call to the url
we give it and will place the content in our page. Below the
re is an example which will load the
the url
'url
' in a pop up called
'our title
':

var popup = Liferay.Popup(




{





title: 'our title',





position:[150,150],





modal:true,





width:500,





height:300




}



);

jQuery(popup).load('url');

It's important to note that if the url is a
portlet url

it must have the windowState parameter set to
LiferayWindowstate.EXCLUSIVE
, because we just want the content produced by the portlet
and not the extra portlet decoration produced by the portal.

To imp
lement a button or link to close the pop up use the following code:


Liferay.Popup.close(this);

This type of pop
-
up is used in several Liferay core portlets like the image gallery (show
pictures), journal (edit template) or my communities (publish to live)
. Look at them for further
examples of usage. Also you can find more information about them in the javascript file:
portal
-
web/docroot/html/js/liferay/popup.js

Window Pop up

This type of pop ups will load in a new window. In order to do that we must set the windowState
parameter in the portlet url to
LiferayWindowState.POP_UP
. This windowState will produce
that the result of calling a portlet url will be shown in another windo
w, like a real pop up. There
are no visual effects asociated, it's a different window.


However, from this window we can still make javascript calls to the parent page javascript
functions as the javascript object
opener

refers to the parent window. There is an example below:

<input type="button" value="select" onClick="


var organizationWindow = window.open('




<portlet:renderURL





windowState="<%=
LiferayWindowState.POP_UP.toString() %>">





<portlet:param name="st
ruts_action"
value="/enterprise_admin/select_organization" />






<portlet:param name="tabs1"
value="organizations" />




</portlet:renderURL>',





'title',




'directories=no, height=640, location=no, menubar=no,
resizable=yes,


scrollbars=yes, status=no, toolbar=no, width=680');





organizationWindow.focus();" />

If we want to close the pop up we just need to do the following:


window.close();

If we

want to close the parent page we can do the following:

opener.close();

This is used in several portlets like the image gallery (show slideShow), enterprse admin (select
organizations for users...)