Hiding actions in Cognos Connection using roles

[DanMotio]

So, I am currently able to hide actions in the portal using roles, except for within the page that opens when you click the "More..." link in the actions column. Does anyone have any ideas on hiding the actions in this "More..." page (IBM calls it the Actions Page) via roles?

I used the methods explained in Cognos Paul's article here to accomplish what I have so far (i.e. hiding actions in the main page).

I have seen the IBM documentation on removing actions from the Actions Page, but it does not allow for role checking.

Any help appreciated, thanks!

[CognosPaul]

Yikes. That post didn't survive the migration well. I've fixed all the paths to include the slashes again.

The actions page is also controlled by an XSL file, the trick is to find the right one. Once it's found, you can use the same method for setting up the whitelist:

Code: [Select]

<out:if test="not(contains($ui_black_list, 'NAME'))">       
</out:if>

NAME being whatever you want to call that group.

I should have some time tomorrow to go through to find the correct sheet, but you should also look. I think there may be one somewhere in the /templates/ps/ folder, but I can't remember exactly off the top of my head.

[DanMotio]

I did take a look around /templates/ps/ at some of the other xsl files last week intending to do just that, but wasn't able to make any headway. I was looking for a similar call to "renderAction".

I'll do some more snooping around later too. Thanks for the response!

[CognosPaul]

Check out ..\c10_64\templates\ps\portal\actions.xts
It will automatically populate the more page based on what was selected and the permissions of the user. The delete box, starting on line 3256, looks like:

Code: [Select]

<!--
============================================================================
Action: Delete
Requires: delete and ('write' or 'setPolicy' access on the object) and 'write' on the parent, and if it's a configuration folder, it must not contain contents.
============================================================================
-->
<xsl:if test="not(contains($ui-obj-act/@exclude, 'delete')) and (($currentCanWrite or $canSetPolicy) and $canWriteOnParent) and not($obj-class = 'configurationFolder' and $hasChildren = 'true') and not($is3rdPartyNSEntry)">
  <xsl:call-template name="render-action">
    <xsl:with-param name="icon-name" select="'action_delete.gif'"/>
    <xsl:with-param name="icon-alt"><xts:string id="IDS_ACT_DELETE_TIP"/></xsl:with-param>
    <xsl:with-param name="link-anchor"><a href="javascript:doDelete()"><xts:string id="IDS_ACT_DELETE"/></a></xsl:with-param>
  </xsl:call-template>
</xsl:if>

Just wrap that with the blacklist code and hopefully it should work.

[DanMotio]

Thanks Paul, it definitely looks like a good find. I haven't, however, been able to effect any changes using actions.xts. I have tried removing entire sections (for instance, the copy, move, delete actions), adjusting if statements, and even removing the file completely, but haven't seen any changes to the Actions page.

I did notice that actions.xts does not appear to have access to the "ui_black_list" variable we were able to use in presentation.xsl, so perhaps that needs to be ported over or there may be a different angle of attack possible. "ui_black_list" is defined in \templates\ps\logicsheets\presentation\main\framework.xsl.

I have been editing the file and then restarting the Cognos service via Windows service utility, if that might make any difference. Should I need to rebuild the ear or something special?

[CognosPaul]

I haven't really had the chance to check this yet. Have you tried deleting or moving the portal.jar file? That contains many of the files, and Cognos will use those before it uses the matching files in the folder.