Fórum

issue with layout.user.private.layouts.modifiable=false property

thumbnail
devaraj s, modificado 11 Anos atrás.

issue with layout.user.private.layouts.modifiable=false property

Regular Member Postagens: 228 Data de Entrada: 21/05/12 Postagens Recentes
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
thumbnail
Juhi Kumari, modificado 11 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Expert Postagens: 347 Data de Entrada: 12/12/11 Postagens Recentes
Hi Devaraj,

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

Regards
Juhi
thumbnail
devaraj s, modificado 11 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Regular Member Postagens: 228 Data de Entrada: 21/05/12 Postagens Recentes
Ya restarted but still same problememoticon
thumbnail
Juan Gonzalez P, modificado 11 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Liferay Legend Postagens: 3089 Data de Entrada: 28/10/08 Postagens Recentes
That propery doesn't exist anymore in 6.1.
You'd have to define permissions using Role->Define permissions.
thumbnail
devaraj s, modificado 11 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Regular Member Postagens: 228 Data de Entrada: 21/05/12 Postagens Recentes
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.
thumbnail
devaraj s, modificado 11 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Regular Member Postagens: 228 Data de Entrada: 21/05/12 Postagens Recentes
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.
thumbnail
Daniel Tyger, modificado 10 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Regular Member Postagens: 105 Data de Entrada: 06/02/13 Postagens Recentes
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 [legacy] 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...
thumbnail
Juan Gonzalez, modificado 10 Anos atrás.

RE: issue with layout.user.private.layouts.modifiable=false property

Liferay Legend Postagens: 3089 Data de Entrada: 28/10/08 Postagens Recentes
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.