I want to configure roles and permissions for a private community such that some of the portlets on a page are locked, but an authenticated member of the community can still add new portlets to the page, and apply that only for their login?

My suspicion is that it is probably not possible with the way the Liferay Portal is implemented. Since users can have their own public and private pages, I would guess that the community private pages can be administered and updated only by users that possess the appropriate roles. Obviously, we would not want to give everyone in the community an administrator role, so I'm wondering what other possibilities may exist.

Does anyone have any ideas here?

Here is an example of what I'd like to do:

A private community includes all authenticated users of portal as its members.
It has only private pages.
Each private page shall have some standard portlets that cannot be moved or removed or configured by anyone possessing the Community Member role.
Users possessing the Community Member role may add more portlets to the pages, but only certain portlets like Stock, Weather, Loan Calculator, etcetera.

Thanks for any input you may have...

A quick one - you definitely have a number of options to play with, some of them are:
- using portlet-level permissions
- embedding portlets into a theme and/or layout, start reading from here.

Another option is to look at using static portlets. Do a search in portal.properties to see how they work.

Thanks for the feedback.

First of all, is it still true that static portlets can be moved by placing a new portlet above a static one?

Secondly, what page permissions must a Community Member have in order to be able to use the "Add Application" functions?

It seems like I might want to use the layout template feature for my global community to "lock" certain portlets on the page.

Recently, though, I tried allowing portlet-level permissions to prevent certain roles from configuring or moving a portlet, but still be able to update the page, and it seems like the page permissions usurp the portlet permissions. Perhaps I just don't have a complete understanding of permissions yet. They seem complex.

Have not used them yet.

Agree and I would re-phrase 'they seem unlimted...'.
And I actually like it, as it allows to design a great range of very simple and easy to manage permissioning rules that are very specific to each project and user environment.
Every deployment usually ends up with only 2 to 5 fixed user groups / user roles that have a clear and natural assignment of responsibilities.

I would also go for layout-based portlet placement (as I have not tried other ways).

Hi Victor,

I have some more questions about the layout-based solution:

• If I define a layout to be used that has some pre-defined portlets in it, what permissions do I need to set on Community Member roles so users can add portlets to the page?
• Will the portlets a user adds only be visible to that user?
• If there are thousands of users as members of the community, and each user customizes the page to his/her preferences in terms of content, will that affect the performance of the page in a noticeably adverse manner?
• Do you have an example that gets into more detail than the previous one you linked to?

I think a bit of clarification is required here (in regards to out-of-box features):
- predefined portlets may exist on layout
- user is able to make additonal portlet deployments within user-owned areas, eg.
if user screenname is testuser, so those areas would be /web/testuser/... and
/group/testuser/...

Area /web/testuser/... will be accesible to everyone
Area /group/testuser/... will be accessible by this user only

I suppose, you can design the layout of your portal pages in such way that user-specific
areas and community areas will be accessed in a flattened way.
E.g. you navigation (top) bar may contain the following tabs:
Tab1 - Home: will render /group/testuser/... where he/she will be able to do what they want, ie. be fully customisable by this user and accessible by this user only
Tab2 - Page 1 of the community this user belongs to,
Tab3 - Page 2 of the community this user belongs to,
TabX - etc.

Will this address your requirements?
If you implement such navigation, I would not expect any affect on performance.

If need something funkier, portal is good enough to accomodate whatever you need by making own software extensions.

Hi Victor,

Thanks for the clarification, and that confirms what I had already suspected. The user's public/private pages are basically his/her own community, and he/she has "Owner" access to the assets within those pages. Defining a layout that automatically places portlets in those pages would allow me to predefine certain content, and allow each user to extend it to meet his/her needs.

I think this makes sense in terms of how portals are generally designed, and I think what I was asking about presents some problems that we would not want to deal with in terms of development and governance. In the short term, I will recommend we follow the paradigms that are already established and well implemented in the delivered solution, and figure out how to define a layout so some of the content is globally provided in a manner that represents a similar basic user experience for all.

Thanks for the dialogue, I definitely think my understanding is more clear and my direction has been determined.