Use Design Locale for Reference ID in 8.4.1

Sorry, no screenshots for this one. Blame InfoSec.

Cognos 10 has a nice little checkbox that you can set to have authors use only the design language when creating reports. Without this option any changes made to any of the non-design languages may break existing reports. Report authors will have to always use the design language when building reports.

Sadly that checkbox doesn’t exist in previous versions. You can, however, manually change the model.xml and add the same tag.

First, back up your model.xml. You don’t want to mess this up.

Place the following code between the </defaultLocale> and <namespace> tags.

 <fixIdsToDefaultLocale>true</fixIdsToDefaultLocale> 

Publish your model, create a new report, drag in a data item into a query. While the data item caption should appear as your active language, the reference should appear in the design language. Remember to close your browser completely before creating the new report, as you may inadvertently use a cached version of the model.

I have only tested this in 8.4.1, but it may work in previous versions. I don’t know and don’t have access to FM of previous versions, so I’d welcome feedback indicating which versions it works.

Hiding objects from lineage

The lineage function is a great tool for users to understand how items are calculated. Business users can use it to fully understand what they’re seeing. The downside of the lineage is that users can fully understand what they’re seeing.

To the best of my knowledge there is no way of telling Cognos to obfuscate a step in the lineage path. This can cause problems if, for example, you use Cognos functions to decrypt a numeric value.

Case in point: an unnamed large company has a field called “Encrypted Data”. The users need to be able to build adhoc queries with the data, but they are not allowed, under any circumstances, to know the decryption formula. A custom database function is out, so it can only be done in Cognos. The users have a tendency to use lineage to double check numbers.

As you can see, lineage leaves a gaping hole in security. Fortunately there is a solution.

The first step is to create a calculation in FM that decrypts the field.

In the properties of the calculation set Is Hidden to true.

Next create a parameter map. Call it Decrypter.
Give it a key. Since the example I’m using is based on the orders table, I gave it the key Order. In the value give it the path of the calculation.

Now for the last step. In the business layer instead of calling the calculation directly you’ll call the parameter map with ‘Order’ as the key.

Now when the user tries to peek in at the lineage he sees this:

Instead of seeing the super secret formula, he only sees the call to the param map. If he doesn’t have access to FM, he will never be able to see the formula now.