Actually it is a good idea.

There is a special mode called EDIT_DEFAULT as far as I recall that is used to edit the preferences shared by all users of a portlet and that is more appropriate than EDIT mode.

It is possible to check if the portlet supports it by reading the mode declared by the portlet.

Edition could be done using the JSF portlet component that is already used in the same application in order to display the EDIT_DEFAULT mode instead of the generic configurator if the portlets supports it.

Thomas, what do you think ?

I think i see what you both mean, and i think you are slightly diverging.

Michael says that preferences are not stored per portlet instance but per user, that's only if you use the Portlet spec API.

The portlet spec API doesn't define an API to modify portlet instance preferences. It means that we would need to open that internal API to a public API.

Using this API, the first cheap solution would be to use the EDIT mode with that internal API (see portal-admin for how to do it).
(As of now you cannot secure a portlet mode for specific roles, so that would let anyone changing the preference for everybody, this is work in progress. You can then use isUserInRole to show part of the GUI for portlet-instance changes, but if your users will still see the edit button, then a blank screen (unless you let them override that preference with a user specific one for example))

To use Julien's (good) idea you would use the same API and create your GUI, you would then be able to change the portlet instance preference from the admin portlet (which can be secured) using the GUI defined by the portlet itself.

Overall i think it's a good idea that should go in Jira

"michaelchan" wrote:
Thank you all for the reply.

Actually, i have attempted a workaround solution but with no success. My approach is as follow:

Use portlet admin mode in JBoss portal, and enable the admin mode for uncheck user role.

It is possible to hide the admin mode from all users apart from admin, to do it, just simply hide all portlet decorations by using empty renderer or write a custom empty renderer.

"michaelchan" wrote:

However, even with admin mode, uncheck users could not change the perferences, this is because all perferences are set to read-only if the user role is uncheck. I tried specifying read-only to false in portlet.xml, but still not success.

"michaelchan" wrote:
So julien do you mean that I could use EDIT_DEFAULT mode with JSF portlet bridge?? Anyway, i will give that a go.

We are getting in more and more confusion.

edit_defaults, is an optional mode defined by the spec, that a portal could support.

It's just a different view of the portlet.

What Julien proposed is that when you click in the admin portlet (implemented with JSF but that doesn't matter) to change the preferences instead of always showing a generic way of changing preferences, you could override that behavior by providing your own view (the edit_defaults mode).

About the other part, do you really want anyone to be able to edit preferences for everybody ?

The related Jira: http://jira.jboss.org/jira/browse/JBPORTAL-2070

"michaelchan" wrote:
i don't want anyone to be able to edit preferences. What I want to achieve is to be able to use a custome GUI for editing preferences at an instance level. Since the portal I am developing do not require user to login and all portlets should maintain the same preferences at an instance level at all time. I just want to find an easy way for system admin to configure portlet instances.

That should clear things up. Thanks for the reply :)

it used to be, I scratched some code a while ago but it was commented for some reason.

we could make at least that mode supported for 2.7 in the normal aggregation mode, in addition of the "admin" mode.

actually in the instance editor we could provide edit_defaults + admin modes

In the meantime, why don't you use the admin mode ?

admin or edit_defaults (or view, help, edit), are just names of modes, what you do with those are just what you want to put in them.

The issue IMO, is that the API to edit those preferences are not part of the public API this will probably not go in 2.7 for that reason.