Default members

When a hierarchy is secured, a new default member on the hierarchy can be specified for the user. For example, if a single member and descendants is granted access, the default member can be modified. In this scenario, the single member is used as the new root of the hierarchy, although the member might not be at the root level.

The following steps determine the correct default member for a secured hierarchy:

  • The original default member is checked to ensure that it is not restricted and not a visible ancestor. If the original default member is unsecured, then it remains the default member.
  • A breadth first search of the hierarchy is done to find the first level with an unsecured member.
    • If the first level with an unsecured member has only the one unsecured member, then the unsecured member is the new default member.
    • If the first level with an unsecured member has more than one unsecured member, or also has a visible ancestor on the level, then their common ancestor is the new default member. In some cases, this common ancestor can be a visible ancestor. In the case of a visible ancestor as a default member, any time a non-visible ancestor member is not the context in the report, the visible ancestor, whose value is always ERR, will be the context.

Any time a hierarchy with a visible ancestor as the default member is not explicitly included in the report, the default member is used in the context, and ERR is the cell values.

Data caching using default members

The same report run by a user with all access and a user with security policies will normally hit the same cache. In general, the secured user needs only a subset of the members that the unsecured user used, because security limits access to the members. However, when the default member differs between the two users, the slice of the cube differs, and a different section of the cache might be required.

The following example shows a cross-tab report of All Product against All Time on Quantity. The security views have the Branches hierarchy secured, but the Branches hierarchy is not included in the report. The default member for the Branches hierarchy is the slicer for the report.

In the case of the unsecured user, with a built-in scope of Grant All Members, the report uses the default member, All Branches, for the context of the Branches hierarchy. The tuple value searched for in the data cache is All Time, All Products, All Branches, Quantity.

Table 1. Example of a cross-tab report using a default member of All Branches
Quantity All Products
All Time 89,237, 091

For the secured user that is assigned to a security view with a scope of Grant United States and descendants, the report uses the default member of United States, for the context of the Branches hierarchy. The tuple searched for in the data cache is (All Time, All Products, United States, Quantity). This differs from the unsecured user's tuple.

Table 2. Example of a cross-tab report using a default member of United States
Quantity All Products
All Time 10,444,575

Because the tuples are not the same, reports that are run by one user would not populate the tuple value in the data cache of the other. Also, because the Branches context is at different levels in the two tuples, the query structure to access the values in the underlying data source differs.