Dimensionality

Many times I come across posts and emails asking for help on specific configuration changes or questions asking for help achieving certain things.

Long story short – you can over-complicate everything if you don’t look at what the standard gives you efore going off and hacking / scripting things in an uncontrolled fashion that will come back to haunt you when you patch or upgrade.

Case in point: Implementing new, custom links which should react to standard security privileges.

As in: Adding a link is documented by Oracle, but how can you make this link react to standard privileges which are tied to your Application Roles?

Oracle provides the out-of-the-box functionality of custom links since several years with all the usual bells and whistles. Problem is, that by far not all options are documented in detail with examples. Top tip here: guess what you will never have everything in the documentation, so the important thing is where to look for more information.

Enter the XSD! Every configuration XML comes with an accompagning XSD style sheet which maps all elements and attributes that the XML supports. Find that XSD and you have all the documentation you could ever want. Following the example of making links dependent on OOTB security privileges:

Here we see one of our administrators (prodney) logged in and seeing two custom links rendered. The “SampleApp V607 Index” and the “Custom Link” which is a link to the documentation. Now we don’t want non-admin users to be able to access the documentation link. So how do we go about this?

The customlinks.xml controls the rendering of custom links as described in the official documentation: https://docs.oracle.com/middleware/bi12214/biee/BIESG/GUID-FF6954BA-2DE0-4422-BA58-05F32936F4FF.htm#BIESG3738

That XML file itself is goverened by the customlinks.xsd file. In there we find the following information on the privilege usage:

<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="iconSmall" type="xs:string" use="optional" />
<xs:attribute name="privilege" type="xs:string" use="optional" />
<xs:attribute name="src" type="xs:string" use="optional" />

Now let’s look back at the documentation and an

<link id="l1" name="OTN" description="OTN open in new window" src="http://www.oracle.com" target="blank" >
   <locations>
      <location name="header" />
   </locations>
</link>

My customlinks.xml says the following for the “Custom Link” one:

<link id="l2" name="Custom Link" description="Instructions on how to insert a custom URL on OBI EE headers" src="http://docs.oracle.com/cd/E23943_01/bi.1111/e10541/answersconfigset.htm#BIESG3738" target="blank" iconSmall="common/info_ena.png">
    <locations>
        <location name="header" insertBefore="home"/>
    </locations>
</link>

Nice. Now let’s add 1 and 1.

“id” and “source” are both attributed of “link” just like privileges which gives us the necessary indication of how to use it.

<link id="l1" name="SampleApp OTN Page"  [skipped...] privilege=" hmm what goes here=?! ">

For the content of the “privilege” attribute we simply refer back to the documentation again:

<link id="l1" name="SampleApp OTN Page"  [skipped...] privilege="privileges.Access['Global Admin']">

Which puts the whole entry in the customlinks.xml to this:

<link id="l2" name="Custom Link" description="Instructions on how to insert a custom URL on OBI EE headers" src="http://docs.oracle.com/cd/E23943_01/bi.1111/e10541/answersconfigset.htm#BIESG3738" target="blank" iconSmall="common/info_ena.png" privilege="privileges.Access['Global Admin']>
    <locations>
        <location name="header" insertBefore="home"/>
    </locations>
</link>

Restarting things will now give me the same resutl for my administrative user “prodney”:

And the correctly secured result for my non-admin user “testuser01”:

Piece of cake.