Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
devaraj s
issue with layout.user.private.layouts.modifiable=false property
November 25, 2012 10:09 PM
Answer

devaraj s

Rank: Regular Member

Posts: 206

Join Date: May 21, 2012

Recent Posts

I dont want normal user to modify his/her private page as i set layout.user.private.layouts.modifiable=false in portal-ext.properties but still user can modify private page.

Can anyone help me, what is the problem with that property??


Thanks in advance
Juhi Kumari
RE: issue with layout.user.private.layouts.modifiable=false property
November 25, 2012 10:30 PM
Answer

Juhi Kumari

Rank: Expert

Posts: 347

Join Date: December 12, 2011

Recent Posts

Hi Devaraj,

Did you restart thr server after that ?? Its working fine for me.

Regards
Juhi
devaraj s
RE: issue with layout.user.private.layouts.modifiable=false property
November 25, 2012 10:44 PM
Answer

devaraj s

Rank: Regular Member

Posts: 206

Join Date: May 21, 2012

Recent Posts

Ya restarted but still same problememoticon
Juan Gonzalez
RE: issue with layout.user.private.layouts.modifiable=false property
November 25, 2012 11:23 PM
Answer

Juan Gonzalez

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1852

Join Date: October 28, 2008

Recent Posts

That propery doesn't exist anymore in 6.1.
You'd have to define permissions using Role->Define permissions.
devaraj s
RE: issue with layout.user.private.layouts.modifiable=false property
November 26, 2012 5:19 AM
Answer

devaraj s

Rank: Regular Member

Posts: 206

Join Date: May 21, 2012

Recent Posts

Juan Gonzalez P:
That propery doesn't exist anymore in 6.1.
You'd have to define permissions using Role->Define permissions.


Really too bad..

For my requirement the property layout.user.private.layouts.modifiable=false is very essential. I tried to follow Juan Gonzalez but not able to meet the property same as layout.user.private.layouts.modifiable=false.

I am producing what steps i have followed. If i am wrong please correct me.

1)role->define permission->user-> define permission->

2) wherever add to page action is there i used to delete that one.
I tried to login as new user ->private page but still he can add content(portlet) to page even that portlet is deleted by admin in roles->define permision.

3) another query is, by using roles->define permission , is it possible to restict the user to manage page also??

I am not able able to understand why liferay team removed that property.??
I think some other new way they have introduced to meet the same behaviour, but i am not getting how i can achieve,


anyone please help me.
devaraj s
RE: issue with layout.user.private.layouts.modifiable=false property
November 27, 2012 1:24 AM
Answer

devaraj s

Rank: Regular Member

Posts: 206

Join Date: May 21, 2012

Recent Posts

Juan Gonzalez P:
That propery doesn't exist anymore in 6.1.
You'd have to define permissions using Role->Define permissions.



Got solutionemoticon Thanks Juan Gonzalez.

solution:
1) control panel->roles-> define permisson
2) under add permission category select sites.
3) uncheck action manage page option.
4) save.
Daniel Tyger
RE: issue with layout.user.private.layouts.modifiable=false property
July 24, 2013 7:20 AM
Answer

Daniel Tyger

Rank: Junior Member

Posts: 54

Join Date: February 5, 2013

Recent Posts

Juan Gonzalez:
That propery doesn't exist anymore in 6.1....


Juan,
Thank you for these tips, but things are a bit confusing for new folks entering the fold from long histories with the flexible approach of the past that is proving out maybe-not-so-flexible-in-some-ways for some of us migrating into the new 6.1>2 constraints and recommendations...

Here is the properties reference for 6.1, still offering this property as available in 6.1: http://www.liferay.com/documentation/liferay-portal/6.1/user-guide/-/ai/layouts which is deceiving when you try and go to source docs like this one to make decisions around these personal communities.

If we migrate in from methods, we are having a database chock full of personal pages along with PreAction extensions that do things like set page permissions, set up mobile pages, or other tweaks to the process...and with that thousands of resource records... Our users have several fixed pages and portlets along with the ability to manage / add pages and resources via CP. Only the fixed portlets would be reposted to the pages if a user deleted them during the session upon the next login...

How do you suggest one reconciles that history with the new methodologies of creating site templates / lars and defining new permission patterns?

Is the overall recommendation to *delete* all those personal communities & resources prior to upgrading, then create a whole template / lar / permissions world for the future?

I am very curious what you and others around the community suggest when deep / long histories surround the makeup and use of these personal communities...

What did Liferay do? Is the public site on 6.1? 6.2? Are you using Site Templates for the personal communities or custom PreAction hook and properties to manage it all?

Thank you for any shared insights / suggestions...
Juan Gonzalez
RE: issue with layout.user.private.layouts.modifiable=false property
July 24, 2013 7:33 AM
Answer

Juan Gonzalez

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1852

Join Date: October 28, 2008

Recent Posts

Hi Daniel,

I don't know what your requirements are, but seems Site Templates and Page Templates should solve your problems (here for more info: http://www.liferay.com/es/documentation/liferay-portal/6.1/user-guide/-/ai/lp-6-1-ugen12-site-templates-0).

The other things, like permissions, should be managed through usual Role permissions in Control Panel as I've told before.

About the property in user guide... Well, sorry, I wasn't accurate enough. Property doesn' exist in 6.1.1, but seems to exist in 6.1.0, that's why appears in that 6.1 documentation.

In your case I would create all needed templates (perhaps you can export a LAR and import it into the Template). Yes, I know that is some amount of time, but I see that way more maintable than change such an important class like ServicePreAction.