Hi Mike,
for controlling the access to cube slices based on user security groups, I would prefer the cube Data Cell Access Security settings instead of no input rules in a BR because of their different purposes and, primarily, performance.
I will expose my reasons, but open to hear different opinions from everyone else:
- After having amended the Cube Data Access Security settings and pressed save, the system should create in the background a dictionary of intersections ==> security settings to speed up the rendering of cube views/validation of imported records.
- Data Cell Access Security settings are used to control RW grants to cube slices and are naturally linked to groups and behaviour like user in/not in group, cell in/not in filter.
- Data Cell Conditional Input settings are used to prevent input against certain intersections for any user group. They are part of the cube settings and they are part of the dictionary intersections ==> security settings.
- Conditional Input defined in a Finance BR is the on-the-fly version of cube Data Cell Conditional Input and is used to prevent input against certain intersections based on certain system conditions, such conditions could be static (e.g. a complicate member filter that is easier to write in a rule) or dynamic (e.g. no input based on WF status, flag values in certain intersections etc.). On-the-fly means that when we render a CV every intersection goes through this BR.
- Data Cell Conditional Input or Conditional Input BR can only prevent input, they cannot block access (e.g. the cell value will be always visible).
- Conditional Input in a BR can check if users belong to specific groups using the methods available from the class BRApi.Security, but every BRApi call is a single connection to the framework DB and this could saturate the channel db server <=> app server (for this reason, in Finance rules, it is suggested to use methods under api class, aka OneStream.Finance.Engine.FinanceRulesApi, because they are all packed within the same db connection).
Apologies for the lengthy answer and for noticing your questions!
Daniele
