Tag: framework

Framework

Bug: In Cognos 10 new packages don’t inherit permissions

| cognospaul

For the past week I’ve been researching a fix to an issue where new packages don’t inherit permissions.

Take the following scenario:

My client has a policy where all packages are saved in specific folders according to the associated project.

All projects are saved in the “Projects” folder with their own specific permissions.

Admins are granted full permission, the project admins are responsible for creating and maintaining the reports, and for granting rights to other users besides the default users for the project. Users are granted only read, execute, and traverse rights. Meaning that they can run any report, but not save anything to the folder. Admins can override this, of course, but that’s their own problem.

In theory, every new item should inherit these settings. Admins can override, but the general practice is to always allow the inheritance. Unfortunately there is a bug in Cognos in which newly created packages overwrite the inherited permissions.

Admins have their execute permissions removed, meaning they can’t run any of their reports, while users have been granted write rights. If the admins don’t notice and fix it immediately, this leaves a big hole in the security.

Fortunately IBM support is hot on the case. There response is that it’s a known issue, but the work-around is to modify the FM.ini file in the configuration directory.

To fix it, backup and open ..cognosc10configurationfm.ini in your text editor of choice.

Find the line

<Preference Name="SetPolicyPackage">FALSE</Preference>

and replace it with

<Preference Name="SetPolicyPackage">TRUE</Preference>

and save the file.

As this is not an XML file, no restart of Cognos is necessary. You probably need to restart FM if it’s open. All new packages will now inherit correctly.

My thanks to the IBM rep who helped me solve it, and to Noam at Libi who opened the ticket for me.

8.4, Framework

Use Design Locale for Reference ID in 8.4.1

| cognospaul

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.

Framework

Hiding objects from lineage

| cognospaul

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.