Hiding Query Items / Folders from Users

[StevenLunn]

Hi all,

We want to hide a number of query items and folders from the majority of Query Studio / Report Authors (or to put it another way only give access to a small number of Query Studio / Report authors).

Have considered a couple of approaches:

1.) Add security in FM. This has wider implications as we need to then add security to all the other parts of the model. This would complicate things and we would have to be very careful that other things are not affected by the change.

2.) Create two versions of the packages - one with a subset of the fields and one with all (either by having basic and full versions of the query subjects and incl or excl them in the package definition or including / excluding the fields in the package definition), publish both, then restrict access to the all versions in Cognos Connection to the relevant group.

Was wondering if anyone has done this without using option 1 and how?

Thanks,

Steve

[MFGF]

Hi all,

We want to hide a number of query items and folders from the majority of Query Studio / Report Authors (or to put it another way only give access to a small number of Query Studio / Report authors).

Have considered a couple of approaches:

1.) Add security in FM. This has wider implications as we need to then add security to all the other parts of the model. This would complicate things and we would have to be very careful that other things are not affected by the change.

2.) Create two versions of the packages - one with a subset of the fields and one with all (either by having basic and full versions of the query subjects and incl or excl them in the package definition or including / excluding the fields in the package definition), publish both, then restrict access to the all versions in Cognos Connection to the relevant group.

Was wondering if anyone has done this without using option 1 and how?

Thanks,

Steve

My advice is that Option 1 is the way to do this - no question. As long as you understand how object security works, it's really easy. What most people get wrong is that they forget two things:

1. As soon as you add the first security rule, the whole model changes from all other objects being available by default to all other objects being not available by default.
2. Object security applied at a higher level in the tree is inherited by all objects below that don't have their own specific object security defined.

What this means is:
a) When you add the first object security rule, you need to remember to grant access to everyone for all the other objects
b) Granting access to everyone at the top level namespace will do this in one hit.

Cheers!

MF.

[StevenLunn]

Thanks for the reply. When you put it like that it doesn't sound so bad so I'll definitely consider that approach as well! Think I was put off by the warning message, the fact that we haven't used security in the model like this and that our model is quite large now and we want to be careful that we don't introduce any issues.