Planning Analytics

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Hi Rohit,

Do you have feeders in that rule?

Did you run SecurityRefresh after updating the rule?

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

No I don't have feeders. (I have not had the need for feeders on security cubes earlier, but have not tried with feeders in this case)

Yes, ran Security Refresh (although earlier I have not had the need to run security refresh on element security values being changed by rule)

Defining the value via Rule makes it dynamic and less cumbersome to maintain. But without Rules it does work but calls for more time in maintaining it.

Hi Rohit,

Do you have feeders in that rule?

Did you run SecurityRefresh after updating the rule?

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Refresh Security is required to enforce the changes for rule-driven security.

It was not needed when the values were static.

No I don't have feeders. (I have not had the need for feeders on security cubes earlier, but have not tried with feeders in this case)

Yes, ran Security Refresh (although earlier I have not had the need to run security refresh on element security values being changed by rule)

Defining the value via Rule makes it dynamic and less cumbersome to maintain. But without Rules it does work but calls for more time in maintaining it.

Hi Rohit,

Do you have feeders in that rule?

Did you run SecurityRefresh after updating the rule?

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Security in '}ElementSecurity_' cubes must be statically stored values-rules are ignored by the security engine during evaluation.

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Thanks.

So I guess a work around could be to create a corresponding duplicate cube - apply rule and use a TI to load values '}ElementSecurity_' cubes and Refresh Security. Would have been easier if Rules worked in '}ElementSecurity_' cubes just like CellSecurity Rules.

Security in '}ElementSecurity_' cubes must be statically stored values-rules are ignored by the security engine during evaluation.

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Why would you need a 'work-around', if you can just call security refresh?

TM1 caches all security, with the exception of cell security, for performance reasons. Security refresh rebuilds those caches and all should be well.

IMHO, if anything, and no worries won't change that over night, I'd argue those cell updates to those stored values in these security cubes should not have resulted in updates to our security caches to begin with and only have been picked up when applying a security refresh.

Thanks.

So I guess a work around could be to create a corresponding duplicate cube - apply rule and use a TI to load values '}ElementSecurity_' cubes and Refresh Security. Would have been easier if Rules worked in '}ElementSecurity_' cubes just like CellSecurity Rules.

Security in '}ElementSecurity_' cubes must be statically stored values-rules are ignored by the security engine during evaluation.

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.

Rules (even with SecurityRefresh) did now work.

As @Emirhan Yıldırım mentioned that "Security in '}ElementSecurity_' cubes must be statically stored values-rules are ignored by the security engine during evaluation.",

so I think to make it dynamic and rule driven - work around would be to create a duplicate cube with Rule and use TI to populate   '}ElementSecurity_' cubes with Static value.

Why would you need a 'work-around', if you can just call security refresh?

TM1 caches all security, with the exception of cell security, for performance reasons. Security refresh rebuilds those caches and all should be well.

IMHO, if anything, and no worries won't change that over night, I'd argue those cell updates to those stored values in these security cubes should not have resulted in updates to our security caches to begin with and only have been picked up when applying a security refresh.

Thanks.

So I guess a work around could be to create a corresponding duplicate cube - apply rule and use a TI to load values '}ElementSecurity_' cubes and Refresh Security. Would have been easier if Rules worked in '}ElementSecurity_' cubes just like CellSecurity Rules.

Security in '}ElementSecurity_' cubes must be statically stored values-rules are ignored by the security engine during evaluation.

Greetings!,

While working on Planning Analytics Cloud environment we are providing READ / WRITE access to elements and groups based on RULEs on different '}ElementSecurity_' cubes. E.g.

# ##Assign WRITE access to N level element for corresponding Sales Group (S001 through S060)
 [] = S: IF(ELLEV( 'D.Sales.Hierarchy',!D.Sales.Hierarchy ) = 0  & ELPAR( 'D.Sales.Hierarchy', !D.Sales.Hierarchy, 1 ) @= !}Groups, 'WRITE', CONTINUE); 

and so on...

Rules work correctly and values are populated in cube. 

Security DOES NOT WORK, when values are derived from RULES. If we disable RULES and enter value manually in  '}ElementSecurity_' cubes then the Security settings WORK CORRECTLY.

Do we know why RULES based definitions would not work here? Or is there any configuration settings to make RULES based '}ElementSecurity_' cubes work correctly?

Thank you.