[peterj]

Notice that the portlet instances only you to choose view access. Thus, personalization does not effect the display of a portlet. That is, any user who can view the portlet can also edit the portlet.

So far, I hve not been able to figure out what 'personalization' means. That is, I have not noticed any difference in behavior or capabilities in the Portal between granting 'view' access versus 'personalization' access at the page or portal level. As far as I can tell, 'personalization' access is meaningless. Well, it does imply'view' access, but nothing beyond that.

[peterj]

!! s/personalization/personalize/

[mifa]

Very strange. What to do if I have a portlet which should be visible for users, and only admin could change it properties (edit-mode of portlet)?
For example in Jetspeed2 it in general without problems.

[zerrt]

I have the same requirement - to be able to have any user see a portlet but only admins be able to use the edit mode. If anyone has figured out how to do this, please post how if you can. It seems to me the personalize permission should be for this, I wonder if it is a bug?

[franco12]

Same wondering ;)

[theute]

This is not a bug. The whole idea of the portal is to let the users customize their portal (next version of portal will include dashboard management).

You want to let the users edit the preferences of a portlet. Let's say you want to let one user display 15 posts per forum page and the other display 20.

That's why we have management portlets (for admins).

That said, one custom state could be an administration state restricted to some roles.

[peterj]

But then what is the difference between assigning 'view' access and assigning 'personalize' access?

[franco12]

For example, my portlet instance has the 3 mods (view, edit, help)
In security options I've only the choice to enable or disable view mode for each roles.
If I choose to enable the view mode of my portlet instance for a role, It will also have access to edit and help mods.

[zerrt]

This is not a bug. The whole idea of the portal is to let the users customize their portal (next version of portal will include dashboard management).

You want to let the users edit the preferences of a portlet. Let's say you want to let one user display 15 posts per forum page and the other display 20.

That's why we have management portlets (for admins).

That said, one custom state could be an administration state restricted to some roles.

I suppose I understand what you are saying about the most common use of the edit mode and that all users should be able to access it if it is used for things like personal settings, etc. This is the intended use for this mode, I know. But I don't think that it should be taken for granted that this will always the case and that the ability to permission the edit mode is not needed. All other portals that I have ever worked with allow you to set permissions on the view and edit modes independantly. Reading this thread, it is clear that cases that need this kind of functionality are not that uncommon.

For my case, since I have no user edit functions for my portlet but I have admin edit functions, it would be convenient for me to use the edit mode of a portlet for admin use. It may not be the common use but it is a valid use in my opinion and should be allowed. It allows me to take advantage of the built in icon in the portal header, etc without having to do extra work.

I looked more closely at the permissions and it looks like the personalize option does set permissions for the edit mode. It's just that you can only set them on portal or page instances. So in theory I could set up a portlet with the edit mode only for the admin role - as long as it is OK that all the portlets on that page have the same permissions. But I can't figure out why it is set up like that. Why not keep the permissions consistent at every level. There is nothing to be gained by limiting the flexibility in this way. It just makes the permission system less fine-grained. Maybe it's just that I am used to doing things a different way and I have to get used to this new way for it to make sense. I know that these kinds of things are being addressed for version 2.6 so maybe all this will be straightened out soon. I'm not sure what dashboard management is, though. What kind of functionality does that include?

Anyway, thanks for the suggestion of creating a custom mode. To create a custom "admin" mode, would I have to create my own layout and render set if I want to add a new icon for the this mode on the portlet header? Maybe it might be easier to just have a link inside the body of the portlet that only appears for the admin role. Then the admin edit functionality can just be a view of the portlet that doesn't need a special mode. Not ideal but it should be fairly easy to do.

I'm sure I'll figure something out. At least I know why what I was trying to do won't work. This forum has really helped me out a lot.

[tajh]

Months later...

I think there is a programmatic way to do this. I have had the same issue, using JBP 2.4. You can implement a custom org.jboss.portal.theme.render.DecorationRenderer, or just subclass org.jboss.portal.theme.impl.render.DivDecorationRenderer (assuming you are using the divRenderer in your *-object.xml either specifically for that portal object or as the default renderer) and override render() and reimplement renderModeAndStateLinks() (because it's a static method in DivDecorationRenderer for some odd reason) .

I will be attempting this. The open question is whether I can find enough implementation in the RenderContext parameter to figure out who the user is and what she can access. Hopefully I can somehow get access to the RenderRequest object, and then I will be able to get all the information I need.

Hope this helps someone else.

[nollie]

This thread is helpful for my current problem, but I'm not sure how to interpret this table:

Object RoleA RoleB Unchecked
 Page1 view view -none-
 Portlet1 view -none- -none-
 Portlet2 view -none- -none-
 Portlet3 -none- view -none-
 Portlet4 -none- view -none-

Re: "-none-", do I include a policy permission that doesn't have an action-name? Do make the action-name '-none-", or do I simply not include the policy permission at all?


I am trying to add security contraints to my pages, but so far I haven't been able to deny my self any instances or pages - I can still see everything.

/portal 2.4.1 and AS 4.0.5

[peterj]

Regarding -none-, the last assumption is correct - do not set any permissions for that role on that object

The key to removing "global visibility" is to make sure that the Unchecked pseudo-role does not have any permissions at any level (portal or page).