Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

MSTR 7.1.3 -> 7.2.2 Security Filters

MSTR 7.1.3 -> 7.2.2 Security Filters

MSTR 7.1.3 -> 7.2.2 Security Filters

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
we have a second table FACT2 that has the key values:
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

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?

RE: MSTR 7.1.3 -> 7.2.2 Security Filters

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.


RE: MSTR 7.1.3 -> 7.2.2 Security Filters

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,

RE: MSTR 7.1.3 -> 7.2.2 Security Filters

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?


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close