Framework Manager Icon Differences

[kmedwards76]

Can someone tell me what the differences are in the icon which is marked with a red square? Notice the Infinity sign or Person sign in the top left of other icons? I recently took over a model in which I am trying to discern how to maintain a similar structure from a Monthly timeline to a rolling 4 week timeline. Since I have created a new Query Subject to include the rolling 4 week information, I have noticed that I obviously didn't create this in the same manner as the the original model author.

Thanks!

[MFGF]

Can someone tell me what the differences are in the icon which is marked with a red square? Notice the Infinity sign or Person sign in the top left of other icons? I recently took over a model in which I am trying to discern how to maintain a similar structure from a Monthly timeline to a rolling 4 week timeline. Since I have created a new Query Subject to include the rolling 4 week information, I have noticed that I obviously didn't create this in the same manner as the the original model author.

Thanks!

Hi,

The person icon in the top left corner tells you that the object in question has Object Security defined for it. The query subject you highlighted does not have this specifically defined.

Cheers!

MF.

[kmedwards76]

Thank you so much!

[bus_pass_man]

You have 4 query subjects in the PNG.  (and 3 folders). 

The last 3 query subjects have facts in them (or more precisely, have a usage of measure. You may want to double check that you don't have something which you want to be used as an identifier or attribute with the usage of measure).

All of the folders and all but the last of the query subjects have object security defined for them.   

The missing symbol is the indicator that object security has been explicitly set on it.  Since your query subject does not have object security explicitly set, it will inherit the object security from its parent.   You should be able to confirm that by logging into one of the reporting tools as members of the various users, groups, and roles which have object security defined and viewing the metadata tree  (object and data security should be unions of the denials).

The Cognos best practice specifies that, when you define object security, to start at the model root node and define a default object security state on the model.  This default state will be inherited by any child object unless that child object ( or an intermediate object) has explicit object security defined for it.  The two options are called lock down and allow and grant then deny or something like that.

You can define object security in non-best practice ways but it gets messy quickly.

The best of the two methods is lock down and allow as that should fail safe.  It is usually better to not allow someone access to see something and fix that than to allow something to accidentally see something. Just being able to say, 'this method will fail safe' is always helpful to say to panicky managers, auditors, etc.

Hopefully, your predecessor followed the best practice so you would be able to fairly rapidly get an idea about the object security state of your model.

[robblob]

bus_pass_man,

These "best practices" you speak of?  Are these documented/posted anywhere for people to reference? 

[kmedwards76]

You have 4 query subjects in the PNG.  (and 3 folders). 

The last 3 query subjects have facts in them (or more precisely, have a usage of measure. You may want to double check that you don't have something which you want to be used as an identifier or attribute with the usage of measure).

All of the folders and all but the last of the query subjects have object security defined for them.   

The missing symbol is the indicator that object security has been explicitly set on it.  Since your query subject does not have object security explicitly set, it will inherit the object security from its parent.   You should be able to confirm that by logging into one of the reporting tools as members of the various users, groups, and roles which have object security defined and viewing the metadata tree  (object and data security should be unions of the denials).

The Cognos best practice specifies that, when you define object security, to start at the model root node and define a default object security state on the model.  This default state will be inherited by any child object unless that child object ( or an intermediate object) has explicit object security defined for it.  The two options are called lock down and allow and grant then deny or something like that.

You can define object security in non-best practice ways but it gets messy quickly.

The best of the two methods is lock down and allow as that should fail safe.  It is usually better to not allow someone access to see something and fix that than to allow something to accidentally see something. Just being able to say, 'this method will fail safe' is always helpful to say to panicky managers, auditors, etc.

Hopefully, your predecessor followed the best practice so you would be able to fairly rapidly get an idea about the object security state of your model.

Thank you, I checked this and the object security is set in the Business Layer, I will continue with this methodology.

[bus_pass_man]

 

These "best practices" you speak of?  Are these documented/posted anywhere for people to reference? 

Here are two places.  IIRC it's also in the FM modelling course.


ftp://public.dhe.ibm.com/software/dw/dm/cognos/modeling/security/security_in_framework_manager.pdf

https://books.google.ca/books?id=4qTEAgAAQBAJ&pg=PA125&lpg=PA125&dq=cognos+object+security+and+allow+grant+deny&source=bl&ots=f4TFxlbDpN&sig=ACfU3U26sXLI_ESypRqaNi7sGaoz-y6kVQ&hl=en&sa=X&ved=2ahUKEwiJrsXel6bjAhXHmeAKHcRWDqAQ6AEwBHoECAkQAQ#v=onepage&q=cognos%20object%20security%20and%20allow%20grant%20deny&f=false