How to disable sections in web content editor

[Andrea Chiodi, geändert vor 6 Jahren.]

Hi everybody.
I'm configuring Liferay 7 GA4.

I need to allow users with a specific role to edit some existent web content, but without additional features, namely I need to hide / disable the sections "Structure and Template", "Small Image", "Metadata", "Schedule", "Display Page", "Related Asset", possibly even Language/Translations and the Title.

Is it possible? Could you please point me to some solution ?

Some additional info:
Currently, I only added the following permission to such a role:
- 'update' for each of the web-content resources the user is allowed to edit
This enable the function "edit web content" from the web-content-display portlet, without the need to access in control panel.

Thanks, Andrea

[Olaf Kock, geändert vor 6 Jahren.]

Andrea Chiodi:

I need to allow users with a specific role to edit some existent web content, but without additional features, namely I need to hide / disable the sections "Structure and Template", "Small Image", "Metadata", "Schedule", "Display Page", "Related Asset", possibly even Language/Translations and the Title.

Is it possible? Could you please point me to some solution ?

There's nothing based on permission that helps you hiding those areas of the UI. However, maybe a ridiculously simple plugin (something quickly built) helps if you only need a very simle content editor. I've demonstrated the concept in 2014. Granted: Needs adoption to the OSGi world and actually more than a weirdly hacked implementation, but with the "ridiculously simple" idea, you might get the nag of it: Build something that's really simple, rather than customizing something that's really complex.

[Andrea Chiodi, geändert vor 6 Jahren.]

Thanks Olaf for your hint, I will probably follow that way.

Unfortunately, in this early phase of the implementation I did hope to use Liferay 'as it is', just configuring it and avoiding to develop ad hoc software.
It is really a pity to discover once more that LR makes simple things complicated, very often ...
:-/

Andrea

[Olaf Kock, geändert vor 6 Jahren.]

Andrea Chiodi:

It is really a pity to discover once more that LR makes simple things complicated, very often ...

There's one angle of this story that you're not covering:
Liferay, as a platform, is everything to everybody. So it needs to provide as much functionality as possible, to match as many usecases as possible - because otherwise it would make things simple, but stop short of being useful.
Your own installation (and configuration) can easily focus on exactly your usecase, and provide as little functionality as required. Where you can (and should) focus, Liferay needs to be as broad as possible.

Making a system configurable on every level that someone might want to configure it sooner or later, first and foremost makes the system more complex. While Liferay provides quite some level of configurability, I'll grant you that this particular usecase is not among the configurable parts.

However, Liferay allows you to solve the problem with just a little bit of extra work - compare that with other systems where you're out of luck. The plugin that I've linked to has been developed during a Webinar, in approx. 30 minutes of time. Granted, it's not production ready, but making it so wouldn't take more than a few hours. The key here is focus: It's deliberately simple and implements exactly the required usecase, better than any configurable complex UI ever could.

Liferay can be everything to everybody - granted, it's a complex system. If you only need a simple solution, it might be overkill for you. If you need a flexible solution with a lot of out-of-the-box platform features, you'll need to be prepared that it sometimes provides a bit more than you need (and be happy about it). And luckily you have the opportunity to simplify where needed. Sometimes this involves configuration through properties, UI values, or even simple custom Java Plugins.

The key here is that you have the option.

In the early stage of your project, I'd suggest that you go with the more powerful editor and train your authors on what they're supposed to do with it. After all, the author/editor will be trackable. I've solved a lot of permission issues by just organizational instructions, simplifying the system a lot.

[Andrea Chiodi, geändert vor 6 Jahren.]

Well, I followed the suggestion and now I have an alternative and simpler way to edit web content.

Obviously, now I need to deny the (not trusted) user from accessing the standard 'edit web-content' form, which has too many and unconvenient functions.
However, unfortunately, as I grant the 'update' permission to his role, Liferay automatically gives him the access to the 'Edit Web Content' menu item of the portlet, which is exactly what I need to avoid.

Any idea to exit from this loop ?

Thank you.
Andrea

[Olaf Kock, geändert vor 6 Jahren.]

I can't currently look up the exact location, but Liferay's components, e.g. the Web Content Display Portlet, have a UI that can be overridden. The process is well documented, probably the hardest part is to find the responsible element in the UI. If you're lucky, there's a component that determines how to edit some content (but I doubt it), in that case you'd have to change the URL or JS-code to open the editor in place.

I'd be curious if you've solved it already (or if someone else could chime in, now that this post is back in the recent changes) and gladly roll a suggestion back into the next incarnation of the "ridiculously simple" chapter.