Member List Business Rule in Data Access Security
Hi All,
We are implementing some updates to the security model in our application, and we are coming across some unfamiliar territory, so we're looking for some input. We are using OneStream version 7.2.4.
We are trying to prevent the user from seeing data for certain Flow members based on information in the Text1 value of the Flow member. Because we don't want the user to be able to see the data for certain Flow members, we decided to use Data Access Security on the cube, with the idea being that if the user tried to access data they weren't supposed to see, it would return "No Access" in the cell. However, the Text1 values for the Flow members vary based on the scenario and time, so we aren't able to use a simple member expansion formula in the Data Access Member Filter, like F#ParentMember.Base.Where(Text1 Contains 'Valid'). We couldn't get XFBRs to work either, leading us to use a Member List BR. We determined that we can get the Data Access security to call the Member List BR... but only once in a set period of time. We're not sure what that set period of time is, but we've been able to run it once a day. Obviously, this is untenable for a solution since we're not able to test the Member List BR in a reasonable amount of time. Therefore, my questions are as follows:
1. Is there a way to "trigger" the Data Access security to run, or change how often it's triggered, in order to be able to test the Member List BR?
1a. When does the Data Access security run? I.e. when is it "triggered"?
1b. Why doesn't the Data Access security run every time a user attempts to access data? The obvious answer is server performance but I wasn't sure.
2. Is there another way to go about this that might be easier to develop and test? We acknowledge the possibility that in order to achieve our goal, we may need to update all cube views to include a Member List BR on the Flow dimension that will filter out the invalid Flow members, but we're trying to avoid that until we have no other options.
Thank you in advance for all responses!
I ran a quick test. Using a memberlist BR works and applies when you first save it. When you then change something in the BR, this is not reflected in the security access right away when you refresh e.g. your cube view. Your observation that this only refreshes every 24 hours is in line with IIS resetting every 24 hours. I restarted IIS myself after a change in the BR and the new security access was then applied in my test cube view.
The answers to your questions are as follows:
1. Yes, when changing the memberlist BR, you need to restart IIS (please note that this might log off active users)
1a. When you press save on the cube, except when you only change something in a BR, as the 'cube save button' does not account for that. For this you need to restart IIS.
1b. Yes, you are correct, the answer is: Performance.
2. Work locally on your laptop or your private cloud and restart IIS as needed. Migrate the final solution to the customers app in the end when testing is no longer required or kept to a minimum.
To restart IIS, I use the Internet Information Services (IIS) Manager on my laptop and press restart.
SAAS customer can press this button (Recycle App Pool) to restart IIS on a given server under System >> Environment:
