I know ALUI Publisher is on the down slope, but until then, it does not mean I should not share some of my findings…Lately, I found something in publisher that does not make sense to me. It has to do with the creation of portlets based on publisher portlet templates. Let me explain the problem…and then the quick fix…
The problem:
Out of the box, when you create a portlet based on a publisher portlet template (i.e. announcement, news, etc…), there is a screen where you are asked to choose a publisher folder where the portlet publisher content should be…When clicking on the “chose publisher folder”, a publisher tree pops up, and you can pick the publisher folder. The tree picker will only show you the folders where you have “producer” access…until now it makes sense since only the “producer” role and above can create folders in publisher.
But what if a user does have “producer” access to a subfolder Z located in the tree structure at X > Y > Z…but does not have producer access to the parent folder X and Y?? Then the tree picker would simply stop showing the tree at X, hence not showing the subfolder to which the user has actually access to…hence problem.
A perfect (and probably common) use case is where you have various publisher sites (i.e. an intranet site, and internet site, etc…) and within each of these, you have various “community-related” publisher folders… (folders that contain the web content of each community). You will want your community administrators (in the portal) to also have “producer” or “folder administrator” role in their “community-related” publisher folder…but not have these roles in the parent publisher folders…they should have “reader” access on these parent folders…
The solution:
By reverse engineering publisher one more time, I found out that this problem can be fixed really easily…basically the publisher tree picker is opened with the following url:
“../folderpicker_frame.jsp?sid="+sessionId+"&showItemCategory=0&itemId="+parentFolderId+"&isMultiSelect=false&rootIsCheckable=true&minRoleId=12”
What is interesting in this url is the last parameter: minRoleId=12. What it probably means is “show only the folders to the users who have at least a role 12 – producer role – assigned to it.” That’s it, we have our solution…By removing this parameter altogether, the tree will now show the folders to which the user has minimum access to (“reader” access), hence fixing the user case explained above:
A producer in folder X > Y > Z will now be able to browse down to the Z folder, where he will be able to create a folder.
And don’t worry, it does not impact core security at all. If the user tries to select folder X or Y as a container for his “announcement” portlet, he will simply receive an error message saying ”you do not have enough access to create a folder”…so no problem.
Detailed instructions:
- Make a backup of the publisher application files \bea\alui\ptcs\6.4\webapp\ptcs.ear and \bea\alui\ptcs\6.4\webapp\ptcs.war (obvious, no?)
- Unpack the publisher archive (ptcs.war)
- navigate to \bea\alui\ptcs\6.4\webapp folder
- create a new dir: ptcs
- navigate to that new dir and execute the following jar command: jar –xvf ../ptcs.war
- edit the extracted file: ./portlet_packages/portlet_create.jsi
- Find the JavaScript functions “ChooseParentFolder” and “NewParentFolder”
- Remove the “minRoleId=12” from the “var url = …” line (1st line in each functions)
- Still in \bea\alui\ptcs\6.4\webapp\ptcs folder, repackage the war by executing: jar -cvf ptcs.war *
- move the newly created war to the \bea\alui\ptcs\6.4\webapp folder: move ptcs.war ../
- navigate to \bea\alui\ptcs\6.4\webapp: cd ../
- update the ptcs.ear file with the following command: jar -uvf ptcs.ear ptcs.war
That’s it…
Before restarting publisher, clean the temp files from the publisher container folders just to make sure your modification is loaded properly.
- \ptcs\6.4\container\tmp\deploy
- \ptcs\6.4\container\work\jboss.web\localhost
As usual, do this at your own risk…and test it well before deploying to production :)
