MSTR 7.1.3 -> 7.2.2 Security Filters

[DebbieKat]

We recently upgraded our development environment from 7.1.3 to 7.2.2
and we are experiencing drastic changes to the way security filters
are applied.

The way it worked in 7.1.3 the security filter was applied to any
tables that were part of the information we were trying to obtain
from our data mart.

For example, if we have a table, FACT1 that has the following key
values: CLIENT_ROLE1_KEY, CLIENT_ROLE2_KEY and CLIENT_ROLE3_KEY and
we have a second table FACT2 that has the key values:
CLIENT_ROLE1_KEY, CLIENT_ROLE2_KEY and CLIENT_ROLE3_KEY,
CLIENT_ROLE4_KEY. Our report wants data from FACT1 and doesn't
require any data from FACT2. However, our security filter only allows
this particular user to see specific clients' data. So the security
filter says something like: WHERE CLIENT_ROLE1 = 'XXX' OR
CLIENT_ROLE2 = 'XXX' OR CLIENT_ROLE3 = 'XXX' OR CLIENT_ROLE4 = 'XXX'.

In 7.1.3, the security filter would be applied to FACT1 based on the
key values in that table. So only the filters against CLIENT_ROLE1,
CLIENT_ROLE2 and CLIENT_ROLE3 would be applied. Our report doesn't
really want any of the data in FACT2. In 7.2.2, the tool is purposely
seeking out data in FACT2 because CLIENT_ROLE4_KEY is in this fact
table and not in FACT1. Even though we aren't requesting any other
fields out of this table.

According to Microstrategy, the way it functions in 7.2.2 is as
designed and the way it functioned before was 'broken'. But now this
is requiring a drastic change in how we do our security.

Has anyone else experienced similar issues upon upgrading? If so, how
are you handling this?

 

[mdl333]

No, but the fact that it was "broken" prevented us from using security filters before. I was not aware that this was supposedly fixed, so I'll try them tomorrow and see if they work as intended.

Mark

 

[FLB]

You are right, we also discovered that the security filter work differently. There is actually a good technote on the MicroStrategy support site that describes the changes.

In your case, I assume that FACT1 can be considered an aggregate (accross CLIENT_ROLE4_KEY) of FACT2, right? If that's the case, then you should change the dimensionality of the metric (check the TechNote, that will be more clear) to CLIENT_ROLE3_KEY Absolute, Standard. [The tool might still go against FACT2 but at least you will get the right numbers!]

2 cents,
Flb.

 

[DebbieKat]

Hi FLB -
Actually, no, it's not an aggregate. It's just that for the data in that particular fact, that client role is not applicable. So, it's still at the same level of granularity. It's a complexity of our data.

You wouldn't happen to know the Technote # offhand, would you?

Debbie