• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (1)

1 Brad Konopik commented Permalink

Thanks for the example, Owen. A couple things. your example 101CustomActionPolicy.xml file does not produce the desired result. You end up with 2 separate ACTION_INJECT_TOKEN properties, instead of having those roles appended.

 
I don't know what that saying "the proof is in the pudding" means, but when crafting custom xml overrides, the "proof" is in the resulting TeamWorksConfiguration.running.xml file (aka: TWCR file) after you restart your server.
 
I refer back to the example directives I supplied when I co-authored Lombardi Knowledge Library article (now IBM TechNote):
 
"How to restrict access to ASSIGN type buttons in the Portal"
http://www-01.ibm.com/support/docview.wss?uid=swg21439738
 
I used to use a liberal sprinkling of "mergeChildren" directives everywhere, but I stripped this example to the minimum of what worked for me:
 
(hopefully the HTML-encoded XML will survive .. it took an hour to get it to look correct in "preview" mode)
 
<properties>
  <server>
    <portal>
      <default-action-policy>
        <action type="ACTION_INJECT_TOKEN">
          <role merge="append">ROLE01</role>
          <role merge="append">ROLE02</role>
          <role merge="append">ROLE03</role>
        </action>
      </default-action-policy>
    </portal>
  </server>
</properties>
 
 
Readers: be advised, the mechanism for overrides changed in the BPM 8.5 codeline. Instead of 101MyCustom.xml files the Action Policy overrides use wsadmin scripting as described here:
 
http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r5m0/index.jsp?topic=%2Fcom.ibm.wbpm.admin.doc%2Ftopics%2Frestricting_access_to_portal_functions.html
 
For BPM 8.5 -- instead of the "pudding" being in the TWCR file, the digested wsadmin directives end up in a file called "cluster-bpm.xml"

Add a Comment Add a Comment