Usability improvements for the permissions UI

[Jorge Ferrer, módosítva 14 év-val korábban]

Hey guys,

We've been working lately on several improvements to the permissions UI that I'd like to share. Also we are working on a last improvement right now for which I'd like some feedback. But, first the improvements:

1) Smarter UI for editing permissions of an specific resource
Previously it only showed the checkboxes checked if that permission was explicitly selected for that specific resource but not if a given role had the permission globally. With the changes we've made if a role has the permission for all resources of the current type the the checkbox is preselected and when hovering a text appears describing where the permission comes from.

Also the role names are now links that take the user to the UI to define the permissions of the role at a broad level. Of course the links are only shown if the user has the appropriate permissions.

Here is an screenshot that shows the resulting UI:



2) More consistent and easier to navigate UI for managing roles

Now all of the screens of the user administration UI show the toolbar and a breadcrumb that allows navigating back and forth. Also, the three most common UIs related to editing a role: edit the properties, define permissions and assign members have been linked through a set of three tabs so that it's much faster to navigate between them.

3) More intuitive and faster adding of permissions to a role (feedback wanted)

The third improvement is not yet finished, although it will be in the next few days. The purpose is to solve some of the issues with the current buttons "Add portlet permission", "Add portal permission". Many people don't know what they are and have to click to find out. Also in portlet permissions there are many entries and often you have to go through several pages to find what you are looking for. One of the reasons for this is that there is a mix of portlets that have real content with those that do not.

The solution we are applying is based on the following changes:

• Substituting the buttons with select boxes to avoid an intermediate step. Also using select boxes it's much easier to expand them to see what each one means. A third benefit is that the browser automatically provides incremental search of the available options (because we've ordered them) which makes it super fast to find what we are looking for.
• Separating the permissions for content from the permissions for portlet instances. The latter are only permissions to view or configure specific portlet types and we think this is a task that is performed much less often.

Here is a screenshot with the result. We'd like to ask for feedback about this improvements and also for further ideas on how to improve it even further.



I'd welcome any feedback in these features.

[David Truong, módosítva 14 év-val korábban]

looks really good

[Ed Shin, módosítva 14 év-val korábban]

Yup, looks great! I think the drop down for Content, Portal and Portlet Permissions is still not so easy to understand, but I think we should go with what you have since it's better than what we have right now. There's no minor suggestions that I can think of that would improve the current design.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Ed, Dave,

Thanks for your comments.

@Ed, I agree that the selection boxes can confuse at first because it's not so common to have three select boxes for navigation. At least once you get used to them it's very fast and easy to navigate. As an alternative I thought of using a menu instead but it would take away too much space at a side of the table. I'm open for suggestions.

Julio has been pushing me to go further in this improvements specially in the UI for selecting the actual permissions of a resource which was a bit clunky. We are quite happy with the end result. I hope you'll like it:



Besides the obvious look improvements it now always uses checkboxes for selecting actions. No more confusing dropdowns to select "Enterprise" or "Communities".

[Bryan Cheung, módosítva 14 év-val korábban]

Jorge,

Something about that whole top navigation area with the breadcrumbs, three tabs, and three drop downs just seems wrong to me. When I just look at it, it's not obvious to me at all what's going on...

Maybe you need a header for the Section, even though you have the Breadcrumb, maybe just having a title that tells you very obviously what you are here to do would help.

I also think maybe changing the wording could help. "Define permission" takes some thinking to figure out what it might mean. And a wise spaniard once told me we should never make the user think. ;)

The three dropdowns is confusing b/c it makes me think selecting three options will filter the list below into an AND of some kind...

What's on the Edit tab?

Maybe there should be a relationship between the tabs, either a 1) 2) 3) or a verbal connection:

Edit who can do what in the Blah blah Role

where "who" = Assign members and "what" = Define permissions"

But I need to know what the Edit tab is for to suggest something better.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Bryan,

I agree. I wasn't completely happy with that overcrowded top part but I wasn't sure how to fix it.

I'll try to work with Nate on it.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Ricardo,

I'm not sure if such a manual exists yet since Social Office is in beta, but I recommend you to ask in the Social Office forum category, since this thread is about a very different topic.

[Olaf Kock, módosítva 14 év-val korábban]

I like the idea of a verbal connection - right now I feel I'm mostly missing verbs and objects in the permissions dialogs. The current information is like "Owner Permissions", "Owner Assign Members", "Owner Delete" - which might be (partly incorrect, granted) commented with "This sentence no verb".

Jorges tooltip suggestion also helps - it gives a bit of context to what I am about to do. I could even picture some always visible text above/below the permissions checkbox table that provides even more context, probably information about what I can not do with the permissions below.

You might be able to tell from this that I'm just starting to fully understand the permissions. But even when they are mastered - there's a lot of whitespace on the permissions pages that can be used for online documentation.

[Mika Koivisto, módosítva 14 év-val korábban]

Nice work Jorge. Looks a lot better than before.

[Jorge Ferrer, módosítva 14 év-val korábban]

Thanks Mika,

I haven't been able to commit it yet but hopefully it'll be available in trunk yet.

What I have committed though is a much smaller but probably more significant improvement. Now whenever a user creates a Blog entry, Document, Web Content, Image, etc. there is a field like this:



When it's checked then Guests have permission to View the content. When unchecked the Guest user does not have permission to view it. The defaults are smart:

• When the content is created from a private page the box is unchecked by default
• When the content is created from a public page the box is checked by default
• When the content is created from the Control Panel private page the box is unchecked by default unless there are no private pages

This simple fix solves many complains of the permission system not working as expected. For example I thought until very recently that the activities portlet was showing activities in private communities such as uploading a document when it should not, but the reason why it was doing so is just because the uploaded document had view permission for guest by default.

This change has been backported all the way to 5.1.x

[Aniceto P Madrid, módosítva 14 év-val korábban]

Jorge

To have a better understanding of Liferay pemissions system I created a spreadsheet with the list of menus and actions where a portlet permission could be set.

That sheet has 83 lines, and it does not include the permissions of every kind of portlet. Some lines are duplicated, but I'm sure some properties are missing.

About 80 possible menu - actions is high enough to be sure permissions UI needs some fixing.

Secondly, in my opinion wording of actions and permissions is noy completely clear.

I you want, we can talk about this.

Anyway, these new designs seem better and clearer than the current ones. Good job!

Aniceto

[Jorge Ferrer, módosítva 14 év-val korábban]

Thanks Ben, Bryan and Aniceto for reviewing the changes and providing feedback.

We are looking for an alternative UI widget for the three drop downs. Currently we are thinking of something along the lines of the "Add Application" overlay which has a quick search and supports grouping of items.

Regarding the verbal connection, the right choosing of words it's harder for those of us who have been using the permissions system for a while, so I'd really appreciate specific suggestions for change.

As Ben says, it always has a cost when the UI changes, so lets try to make 5.3 so good that we don't have to change it in a while

[Jason E Shao, módosítva 14 év-val korábban]

My first thought looking through the new mockups is: there probably needs to be some more contextual help inline that describes to admin what the different scopes are - though I may be prejudiced by dealing with so many new admins recently.

Aside from that, I tend to agree with the comment that the 3 boxes in parallel looks to be something like a filter - I wonder (but have trouble visualizing) if a flat presentation (more master-detail) would scale better - e.g. 3 columns with all entries always present, and a visual indicator on each entry to show status. Ugh. need to draw some pictures, having trouble visualizing this clearly.

[Ben Starr, módosítva 14 év-val korábban]

These improvements look good to me though I think there is still some refining to do, particularly in relation to the three drop-down boxes. At the moment it is not clear enough what the drop-down boxes do and how they relate to other parts of the UI. It took me a while to get used to the current permissions UI but now that I understand it I don't mind it too much. I think the main advantage of these changes is being able to see all of the directly and indirectly assigned permissions on one page. It would be good to get this functionality to a stable state and then be able to leave the UI alone for a while. I think one of the problems at the moment is that the UI changes often and so you have to re-learn it. The reality is that the permissions functionality is fairly complex so I don't think you can ever create a perfect UI that you can expect novice administrators to understand straight away. That doesn't mean that the existing UI can't be improved or that more help couldn't be provided within the UI.

[Bryan Cheung, módosítva 14 év-val korábban]

Good pointas, Ben.

Jorge, I'm looking forward to what you guys come up with. Maybe you and I can also have a conversation about how to implement a "verbal connection."

[Jorge Ferrer, módosítva 14 év-val korábban]

Hey guys,

After the overwhelming feedback regarding the three select boxes we've changed it. I've been in the LA office with Nate discussing different options and we've ended up choosing the simplest one (which we should've know is almost always the best): a single select box with optgroups. Here is a screenshot of how it looks like when displayed:



And here is how it looks like when one item is selected:



Thanks everyone for your feedback.

The next steps are going to be related to the backend:

• Support configurable permissions for Owner
• Make the "public" checkbox default dependant on the parent (first step towards full permission inheritance)
• Move the "permissions" action into the edit form of all entities. That way it's in the same place when you edit than when you create. It will also use an overlay so that you don't loose context. (ok, this is frontend but makes the backend easier to understand ;) )

[gerald hemmers, módosítva 14 év-val korábban]

Hi Jorge,

It is looking way better with just one simple drop down box. I'm a usability expert / user interface designer for over 10 years now. I'm playing around a lot with liferay lately (first 5.0.1 and now 5.2.3) If you need any direct expert review on some new design ideas or design issues you have just let me know. I'm not a programmer, but i have some time left during the day/night to give a expert review on your ui design changes or ideas (I really have the feeling that i have to give some back to you guys and i would like to be of some support in my own proffessions !! i love liferay ). Just let me know if i can be of any kind of support. grz, gerald

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Gerald,

Thanks a lot for your feedback and for your offer to help. We can certainly get a lot of help from a usability expert. Right now we are focusing the usability efforts in the permission UI. We've already improved quite a few things but if you have specific ideas or new designs for even further improvements that would be very valuable.

[gerald hemmers, módosítva 14 év-val korábban]

Hi jorge, I'm just changing over from 5.0.1 so i'm just playing around at this moment i just started to keep a track list of all things i'm wondering about but it is to soon to give you any direct feedback at this moment. What would be the best way to drop all my thoughts? throught this forum or through my community page? When i will get deeper into the new system i will let you know my thoughts and i will take a look at the current design permission UI later on. At this moment i'm just finding my way in the new interface so i'm not sure if things are unclear because i'm missing out stuff or because of a possible design flaw. But i will keep you posted of my findings.

[Ben Starr, módosítva 14 év-val korábban]

Hi Jorge,

The single drop-down looks like it should work well. The next steps sound like good improvements too. I think one of the confusing concepts with permissions is the difference between specifying what permissions an object has and what permissions other users have on that object (e.g. "Permissions" and "Define Permissions" actions for a role). I can't think of any alternative terminology that might make this clearer. The best solution might simply to explain clearly on the action page what the action does (e.g. "Specify what permissions users have on this object" for "Permissions" and "Specify what permissions this object has on other objects" for "Define Permissions" or something similar). It is important that these concepts are presented consistently and although it might not be entirely clear in the current version of the system it is at least presented consistently and you can fairly quickly get the hang of it.

Ben

[gerald hemmers, módosítva 14 év-val korábban]

What about something like 'object permissions' and 'world permissions' or something ...

[Jason E Shao, módosítva 14 év-val korábban]

gerald hemmers:

What about something like 'object permissions' and 'world permissions' or something ...

The terminology I think is hard to clarify (epecially briefly). My first thoughts were:

"Administrative Permissions" + "Member Permissions" but I'm not entirely happy about that. Perhaps starting with a phrase would help: e.g. "What actions Users/Groups/Roles can perform on this object" vs "What actions members of this object can perform".

[gerald hemmers, módosítva 14 év-val korábban]

quote ' Make the "public" checkbox default dependant on the parent (first step towards full permission inheritance)' , is a nice option, i'm justplaying around with the webshop and i changed the permission , next step is to change the permission of each child object. What about including an option like ' change the permission to the child objects' wich wil set the permissions to the child objects (for example shop item in a catogory) the to same setting as the catagory. This should be an extra option because i can imagine that you don;t want to change al the child object automaticly...

Probably would be nice with other parent child relations as well. So i'm talkin about changing setting with allready created parent and child objects.

[Julio Camarero, módosítva 14 év-val korábban]

Hi all,

we have been working on some of the permissions improvements that Jorge commented several messages above and we have already commited two of them:

- Owner default permissions can be defined in the resource action files. The same as now you can define guest defaults or community defaults, you can also define owner defaults. If it is empty, then all the permissions will be given (as it was being done before). (LPS-3902)
Below there is an example:

               <guest-defaults>
			<action-key>VIEW</action-key>
		</guest-defaults>
		<guest-unsupported>
			<action-key>ADD_DISCUSSION</action-key>
			<action-key>DELETE</action-key>
		</guest-unsupported>
		<owner-defaults>
			<action-key>VIEW</action-key>
			<action-key>DELETE</action-key>
		</owner-defaults>

- resource-action files can be overwritten from Ext Environment. You just need to create a file called the same as the original but ending in ext. (LPS-3904) For example, for Blogs permissions we now have blogs.xml in portal-impl/src/resource-actions/ , but from now on, that file can be overwritten from Ext Environment with the file ext-impl/src/resource-actions/blogs-ext.xml

.... and more improvements will come soon.....

[Ben Starr, módosítva 14 év-val korábban]

Hi Julio,

Thanks for the information. These improvements sound good. If the owner defaults does not include the "permissions" permission would that prevent them from setting the initial permissions that the object has? That is kind of what I would like to see but how would it allow you to let an administrator change the permissions but not necessarily the creator (wouldn't it just turn it off for both of them)? I must say that I don't quite understand how the owner of an object is determined. Who becomes the owner if the person who originally created it has their account deleted?

Ben

[Dmitry Babain, módosítva 14 év-val korábban]

This is great! But i don't think that it's enough. I think that this kind of permissions (default owner) should be scope-related.
And since you can hardly change permission settings through xml in real time and much less probably set them differently for different communities - which is the real world scenario, i guess, - then why bother with xml and not start with db entities?

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Dmitry,

Thanks for the feedback. One common use case for making it configurable through the XML file is that for some certain types (for example forum posts) it does not make sense to allow the author to have all permissions (for example "Permissions" or even "Delete" in some cases).

Being able to change such default for some scope of the data is definitely very powerful but also much harder to implement. We will consider implementing it as we keep going forward though. If you want to give it a try to help get it ready sooner it would be appreciated.

[Dmitry Babain, módosítva 14 év-val korábban]

Yes, there are a lot of use cases which will make me want to change default permissions.
As i see it, there are 3 type of systems which can be developed with liferay:
- corporate style, where company owns all content and where almost everything is "forbidden" and most permissions shoud be "off" by default
- social style, where every user owns his content and most user-related permissions are "on"
- mixed style, where some content belongs to user and some to company or "community".

So you've implemented a solution for 2 out of 3, and that is really great.
As for the coding, then i won't be of big help. Insufficient skill

[Ben Starr, módosítva 14 év-val korábban]

I think the incremental approach that is being taken to implementing these changes is a good idea.

Ben

[Jason E Shao, módosítva 14 év-val korábban]

Jorge Ferrer:

Being able to change such default for some scope of the data is definitely very powerful but also much harder to implement. We will consider implementing it as we keep going forward though. If you want to give it a try to help get it ready sooner it would be appreciated.

What about more easily changing the default for a given scope - say a particular instance of a message board, or forum?

E.g. I've often wished in certain communities, or instances I could over-ride the default permissions on new objects - as a board or other administrator. Instead of being restricted at the instance level to always default to the same permissions.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jason,

Agreed, that would be simpler to implement. Still not sure how that would be done UI wise though, any suggestion?

[Jason E Shao, módosítva 14 év-val korábban]

Jorge Ferrer:

Hi Jason,

Agreed, that would be simpler to implement. Still not sure how that would be done UI wise though, any suggestion?

Well, my first thought was something along the lines of another config tab that could be labelled "default page/post/etc permissions" and the usual permission picker grid. I should try to toss together a UI mock.

On the off note - have you guys seen Balsamiq? They have a plugin for JIRA that embeds a lightweight sketch style UI mock builder, lets you define them right inline in JIRA issues, which rocks -- we're evaluating it internally, but they have a free OS license.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hey guys,

More good news. Brian just finished an additional improvements to make permissions more useful. In 5.3, the view permission will be automatically (dinamically) propagated through parent-child hierarchies.

In other words, if you don't have permission to access (view) a folder you will never be allowed to access its documents directly. This behavior matches much better what most people will expect since it that's the way most operating systems work.

This change affects the Document Library, Image Gallery, Bookmarks, Message Boards and Shopping.

See http://issues.liferay.com/browse/LPS-4078 for more details.

[Jason E Shao, módosítva 14 év-val korábban]

Jorge Ferrer:

In other words, if you don't have permission to access (view) a folder you will never be allowed to access its documents directly. This behavior matches much better what most people will expect since it that's the way most operating systems work.

Sounds like a good improvement. I do wonder if there needs to be a separate "browse?" permission governing directory listing (or setting?) e.g. I can think of many circumstances where web style - you *can* access it directly, but not browse to it - is exactly the behavior I'm looking for.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jason,

I think that's a good idea and I had been thinking about it too, but I couldn't figure out how it would work so that it wouldn't make things more complicated.

Can you elaborate a little bit more about what would be the differences between BROWSE and VIEW both when setting the permissions and when checking the permissions?

[Jason E Shao, módosítva 14 év-val korábban]

Jorge Ferrer:

Hi Jason,

I think that's a good idea and I had been thinking about it too, but I couldn't figure out how it would work so that it wouldn't make things more complicated.

Can you elaborate a little bit more about what would be the differences between BROWSE and VIEW both when setting the permissions and when checking the permissions?

Hmmm... well if I try to trace out some stories, I think I end up with:

• Portal Admin uses image gallery to upload images which we want to embed in content (and manage with the Image Gallery) but not allow users to browse or enumerate
• User wants to setup document library for "drop-box" style functionality

So, at a thought it seems like a "BROWSE" or perhaps "LIST CONTENTS" permission and an "ACCESS" instead of VIEW really only applies to folders and containers... and would likely default to being on.

In terms of permission checking, I think our scenario would like like (hmm... this'd be a nice easyb specification...) :

given "a folder with LIST CONTENTS set to false"
when "a user attempts to list the contents"
then "user is denied"

given "a folder with LIST CONTENTS set to false"
when "a user attempts to access a file contained in the folder
then "the parent folder's permissions are checked, and if ACCESS == true return the file"

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jason,

Ok, that makes sense. How about if we leave VIEW as it is (for backwards compatibility) and make it equal to LIST CONTENTS?

ACCESS would be a new permission that would allow direct access to the documents.

This would be easy to implement and fully backwards compatible.

[Jason E Shao, módosítva 14 év-val korábban]

Jorge Ferrer:

Hi Jason,

Ok, that makes sense. How about if we leave VIEW as it is (for backwards compatibility) and make it equal to LIST CONTENTS?

ACCESS would be a new permission that would allow direct access to the documents.

This would be easy to implement and fully backwards compatible.

That sounds pretty reasonable - especially with some wonderful contextual cues sprinkled into the UI in terms of the distinction between the 2.

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jason,

I've just finished implementing it. Check http://issues.liferay.com/browse/LPS-4238 for details.

I've also tried to implement your proposal of adding contextual help because I agree it would be very useful, but unfortunately I've run into limitations related to how SearchContainer deals with column names. That means that it would take more time than I have right now. Any help on this will be appreciated.

[Jonas Yuan, módosítva 14 év-val korábban]

Hi Jorge,

Thanks. Where are the permissions on web services? How do users control authentication around these web services?

http://localhost:8080/tunnel-web/axis

Is it possible to setup web service admin account for this?

For example, there is a user "wsadmin", an web service admin, it has full permissions on the web services. But it is not a portal admin. That is, the user "wsadmin" is not a admin or a regular user in the portal. Can we add the permissions on the web services and provide capability to assign web services permissions via roles?

Jonas Yuan

-----------------
Liferay Books

Liferay Portal 5.2/5.3 Systems Development
Liferay Portal 4.4/5.0 Enterprise Intranets

[Jonas Yuan, módosítva 14 év-val korábban]

Hi Jorge,

Great job. The new permission UI looks wonderful. I like it.

here I have a question. The previous permission (Algorithm 2) UI provides capabilities to assign permissions via users, organizations, usergroups, regular roles, community roles, community and guest. The new permission (Algorithm 5) UI provides capabilities to assign permissions via roles only. Does it miss any things in the new permission (Algorithm 5) UI?

permission (Algorithm 2) UI


permission (Algorithm 5) UI


Thanks

Jonas Yuan

-----------------
Liferay Books

Liferay Portal 5.2/5.3 Systems Development
Liferay Portal 4.4/5.0 Enterprise Intranets

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jonas,

Thanks, I'm glad you like it.

Exactly, algorithm 5 (and 6) is fully RBAC (Role Based Access Control) which means that all permissions go through roles. That eases the administration and is much faster to check. Algorithms 1-4 are left because in some scenarios the extra flexibility is needed.

[Jonas Yuan, módosítva 14 év-val korábban]

Hi Jorge,

Thank you. It is very nice that permissions "ADD_USER" and "ADD_ORGANIZATION" are configurable via roles. But the functions of "Custom Attributes" and "Export" are hard-coded to the role (RoleConstants.ADMINISTRATOR). Why not make the functions of "Custom Attributes" and "Export" as permissions (actions)? Thus users can assign permissions "Custom Attributes" and "Export" via roles.

	<c:if test="<%= PortalPermissionUtil.contains(permissionChecker, ActionKeys.ADD_USER) %>">
		<portlet:renderurl windowstate="<%= WindowState.MAXIMIZED.toString() %>" var="addUserURL">
			<portlet:param name="struts_action" value="/enterprise_admin/edit_user" />
			<portlet:param name="redirect" value="<%= currentURL %>" />
		</portlet:renderurl>

		<span class="lfr-toolbar-button add-button <%= toolbarItem.equals(" add") ? "current" : stringpool.blank %>"&gt;<a href="<%= addUserURL %>"><liferay-ui:message key="add" /></a></span>
	</c:if>


	<c:if test="<%= RoleLocalServiceUtil.hasUserRole(user.getUserId(), user.getCompanyId(), RoleConstants.ADMINISTRATOR, true) %>">
		<liferay-portlet:renderurl windowstate="<%= WindowState.MAXIMIZED.toString() %>" var="expandoURL" portletname="<%= PortletKeys.EXPANDO %>">
			<portlet:param name="struts_action" value="/expando/view" />
			<portlet:param name="redirect" value="<%= currentURL %>" />
			<portlet:param name="modelResource" value="<%= User.class.getName() %>" />
		</liferay-portlet:renderurl>

		<span class="lfr-toolbar-button custom-attributes-button"><a href="<%= expandoURL %>"><liferay-ui:message key="custom-attributes" /></a></span>

		<span class="lfr-toolbar-button export-button"><a href="javascript:submitForm(document.hrefFm, '<%= themeDisplay.getPathMain() %>/enterprise_admin/export_users');"><liferay-ui:message key="export" /></a></span>
	</c:if>

Does it make sense?

Thanks

Jonas Yuan

-----------------
Liferay Books

Liferay Portal 5.2/5.3 Systems Development
Liferay Portal 4.4/5.0 Enterprise Intranets

[Jonas Yuan, módosítva 14 év-val korábban]

Hi Jorge,

The UI of assigning permissions in Control Panel got cut-off if permission actions number is big (more than 9).

How to fix it?

Thanks

Jonas Yuan
-----------------
The Author of Liferay Books:
Liferay Portal 5.2 Systems Development
Liferay Portal Enterprise Intranets

UI - Assigning permissions in portlet


UI - Assigning permissions in Control Panel

[Jorge Ferrer, módosítva 14 év-val korábban]

Hi Jonas,

Good catch. Could you create a JIRA ticket and assign it to Nate?

[Jonas Yuan, módosítva 14 év-val korábban]

Hi Jorge,

Thank you. JIRA ticket was created. Need admin's help assigning it to Nate.

http://issues.liferay.com/browse/LPS-5339

Jonas Yuan
-----------------
The Author of Liferay Books:
Liferay Portal 5.2 Systems Development
Liferay Portal Enterprise Intranets