Security groups use in rules?

[mmckimson]

To meet end user requirements I am trying to construct a number of rules and processes that eliminate a number of date related maintenance functions as to whether or not time periods in a cube are writable. For the most part the following rules for the data entry cube the end user sees accomplishes this task:

Code: Select all

['Oct', '2013 Forecast'] = N: IF(DB('Product Forecast Flags', 'Oct', '2013 Forecast', 'Forecast Flag') @= 'Closed',
	DB('Product Forecast Data', !dimCostCentersProductForecasting, !dimProductCategory, !dimProductLine, !dimProducts, 'Oct', '2013 Forecast', !Quantity),STET);

What this rule does of course is look to the forecast flag in an "access cube" that is automatically set by a chore that runs on the first of every month. If it sees "closed" it pulls data from a cube, otherwise the cells defined by this rule are writable. Works perfectly.

However, the end user has added one more requirement, and that is to also at a specific date in the month (the 10th let's say), make the intersection of cells as shown above "writable" for only one security group, and "read" for all others.

Assuming I had the following security groups:

GROUP A
GROUP B
WRITABLE GROUP

While the following ignores the date portion of the requirements which I can figure out, Is it possible to look at the group of the current logged in user so that before applying the rest of the rule, or something like this:

Code: Select all

['Oct', '2013 Forecast'] = N: IF ("WRITABLE GROUP", STET,  IF(DB('Product Forecast Flags', 'Oct', '2013 Forecast', 'Forecast Flag') @= 'Closed',
   DB('Product Forecast Data', !dimCostCentersProductForecasting, !dimProductCategory, !dimProductLine, !dimProducts, 'Oct', '2013 Forecast', !Quantity),STET));]

While I'm sure that this wouldn't work, it's what I need to do. If someone can point me in the right direction, it would be great!
Mike

[declanr]

I think you'd be better off applying a rule (or using a TI possibly scheduled by a chore) to update an }elementsecurity cube.

Just keep in mind that if you go down the route of using rules you will need to look into using securityrefresh in a TI or something.

[mmckimson]

I think you'd be better off applying a rule (or using a TI possibly scheduled by a chore) to update an }elementsecurity cube.

Just keep in mind that if you go down the route of using rules you will need to look into using securityrefresh in a TI or something.

Updating the }elementsecurity cube doesn't quite get me where I need to get, as the rule has to cross two dimensions (time, version) with of course different combinations based upon the user group, which seems to indicate the need to use cell level security which I would like to avoid if possible as this security "exception" really only applies to a single group. That was why I was hoping to be able to incorporate the security group in the cube rule itself.

Mike

[declanr]

I think you'd be better off applying a rule (or using a TI possibly scheduled by a chore) to update an }elementsecurity cube.

Just keep in mind that if you go down the route of using rules you will need to look into using securityrefresh in a TI or something.

Updating the }elementsecurity cube doesn't quite get me where I need to get, as the rule has to cross two dimensions (time, version) with of course different combinations based upon the user group, which seems to indicate the need to use cell level security which I would like to avoid if possible as this security "exception" really only applies to a single group. That was why I was hoping to be able to incorporate the security group in the cube rule itself.

Mike

You can apply element level security against both dimensions.

If User A has "Write" access to "Month A" and "Read" access to "Month B"
"Write" access to "Version 1" and "Read" access to "Version 2"

A + 1 = "Write"
A + 2 = "Read"
B + 1 = "Read"
B + 2 = "Read"

[Andy Key]

You say this is a data entry cube, do I assume that at some point you copy this data to the Product Forecast Data cube? Otherwise it seems to me that for the first 10 days of the month the data is effectively locked and comes from another cube, then on the 10th the security changes and the cell is STETed - which replaces any data that would have been shown from the other cube with zero*, then someone from the Writable group enters a number, then later on in the month, or at the start of next month, I assume the security is reapplied and the data reverts to coming from the other cube, therefore overwriting the data that the Writable person entered.

If you are not copying the data from your data entry cube to the Product Forecast Data cube, don't you just need to allow your Writable group access to the other cube instead?


*Unless you are on an older version of TM1 than your sig says, or you have the RulesOverwriteCellsOnLoad=F parameter set and you have previously entered data into the cell