Sorry, fat fingered something and it posted before I was done!
So the example is from the portlet-instances.xml. The role is defined for the portal and it is the correct name (not the description). What am I missing?
Both posts you reference seem to deal with pages rather than portlets. I assume they should work in a similar manner... correct. Your comment about things not working via the descriptor files if the database already has been initialized is interesting. Maybe it is the root issue here?
Of course, changing the settings in that file might not work unless you are starting off with a clean installation, even with setting 'if-exists' to 'overwrite'. (I am not very trusting of 'overwrite', some changes seem to go through ok, others just don't make it.) But if your are attempting to put together a custom portal to deploy, that file is the perfect place to make such changes.
I've also tried adding the following to the *-object.xml that is used to configure the portal. With the overwrite option set. However it doesn't seem to make any difference. I'm not sure one can associate a security-constraint with the window... seems like I saw a note about that somewhere.
<window> <window-name>VacationBalance</window-name> <instance-ref>VacationFlex</instance-ref> <region>left</region> <height>1</height> <security-constraint> <policy-permission> <role-name>employees</role-name> <action-name>view</action-name> </policy-permission> </security-constraint> </window>
Portlet window security is ignored - you must secure portlets at the instance level. Then if a user has view access to a page but does not have view access to a portlet instance whose window is on that page, that portlet window does not show up.
Is there any way to manage this outside of the portlet application's portlet-instances.xml file? I.e. in our custom *-object.xml file? The reasoning for us to need this is that our user roles may be dynamic and redeploying our entire system's EAR just to update a single xml file in a single portlication's WAR is a bit heavy handed.
We keep our topology in a *-object.xml file in a separate "skeleton" WAR that can be deployed independent of the portlications' EAR. Hence the *-object.xml being an ideal location for us to manage this configuration.
Only permissions to pages and portals can be managed in the *-object.xml file.
Besides, even if it were possible to place instance permissions in *-object.xml, it might not do what you want. Both the portlet-instances.xml and *-object.xml file are used to initialize information about a portlet in the database. After that, all management of the portlet is done via the information in the database. While there is an if-exists tag you can place in those files, its actual behavior is sometimes not what you expect. In your case, I could see both the old and new permissions being resident in the database after the update.
My recommendation is to always set if-exists to "ignore" and once the information has been loaded into the database to use the admin portal to do all management.
The Admin Console is fine except for the need for this to be automated from deployment scripts and reproducible w/o manual intervention.
Our solution is going to be implementing an automated mapper for building out our individual portlet-instances.xml permissions across the dozen or so portlet application WARs that are in our deployment package.
Will be adding this to the list along with a *-object.xml topology exporter utility.
On a purely academic level, it doesn't make a lot of sense to be binding the instance security configs with the web app deployment file in a portal framework/topology. This situation is an excellent example why, actually... we have four separate "portals" being hosted on one server but sharing certain generic components. If one portal's security profiles and portlet permissions need modification it will mean a re-deployment of the entire EAR, rather than just a secodary configuration WAR (like what we're doing with managing topology in a separate WAR). Based on experience with a number of other portal frameworks this level of separation can be very valuable when measuring risk/impact of deployment execution.
Thanks for the info!