When OLAP Server calculates a value, access rights typically are only checked for the “target” of the calculation, i.e. the cell path(s) that were requested. Access rights to “source” cells for the calculation are not checked. Source cells are all cells necessary to calculate the value for the requested cell. For example, if a user has no access (“N”) to the element “January” in a “Months” dimension, but does have access to that element’s parent “Qtr. 1”, and requests the value for the latter, they will get the aggregated value that includes the value of “January”. In this way, the result of a cell will be consistent for every user who retrieves that cell’s value.
Rule calculations work in a similar fashion. If a user retrieves a rule calculated value, again, access rights are not checked for the source of the rule calculation. This includes element access, as well as cube access if the rule fetches a value from a different cube within the same database. If a user has “N” access to the year element “2013”, but does have access to “2014”, and a rule is defined on the “2014” slice as: [‘2014’] = [‘2013’], the user will see the values here.
An exception to this circumvention of access rights are rights on database objects, defined in the system cube #_GROUP_DATABASE_DATA. If a rule fetches values from a different database, the user retrieving the value must have at least read access (“R”) to the database from which the value is fetched. The reasoning for this is to allow for “multi-tenancy” scenarios, where databases are to be “shielded” from each other.