As a side note/finding (and sorry to deviate) - what I found somewhat interesting is the following: Combining mutliple analytic privileges for objects contained within the view did not produce the expected result. For example, I was thinking you could modularize the analytic privileges like this.
Provision a user with one role with all the analytic privileges for the views they should be able to access and one role for the analytic privileges that would restrict the attribute views contained within the previous views. Essentially matrixing the views with the allowed master data, for example a user may always be restricted to AT_MATERIAL-Material Group = "A" no matter what analytic views they use, and should be able to exceute AN_COPA, AN_INVENTORY, etc as new views are created. Logically, this seperates the actual views from the master data and would make maintenance for large users easier (in my mind) as new views are rolled out.
However, in some testing - I performed the above and it looks like the restriction in the attribute view role is not being enforced. When the user goes to data preview they can still see ALL data in the analytic view AN_COPA, even if they have an analytic privilege assigned that is based on the AT_MATERIAL = 'A'.
Granted Roles: PUBLIC
SQL Privileges: _SYS_BI (Execute, Select), _SYS_BIC (Execute, Select), REPOSITORY_REST (Execute)
Analytic Privileges: AP_AN_COPA, AP_AT_MATERIAL_MATKL_A
System Privileges: None
Package Privileges: COPA, MASTER_DATA
Analytic Privilege: AP_AN_COPA
Views: AN_COPA, no restrictions
Analyitc Privelege: AP_AT_MATERIAL_MATKL_A
Views: AT_MATERIAL, restiction on MATKL = "A"
It seems that maybe the logical OR operation is being performed for authorization and the analytic privilege on the AN_COPA view with no restiction on MATKL is being picked as the winner?
Thoughts?
Thanks,
Justin