getter Cube.restrictions: MutableMapping[str, HierarchyMembershipCondition[Literal[‘IN’], bool | int | float | date | datetime | time | str] | MembershipCondition[LevelIdentifier, Literal[‘IN’], bool | int | float | date | datetime | time | str] | RelationalCondition[LevelIdentifier, Literal[‘EQ’], bool | int | float | date | datetime | time | str] | LogicalCondition[HierarchyMembershipCondition[Literal[‘IN’], bool | int | float | date | datetime | time | str] | MembershipCondition[LevelIdentifier, Literal[‘IN’], bool | int | float | date | datetime | time | str] | RelationalCondition[LevelIdentifier, Literal[‘EQ’], bool | int | float | date | datetime | time | str], Literal[‘AND’]]]Mapping from role to the corresponding restriction. Restrictions limit the data accessible to users based on their roles.
- Restrictions on different hierarchies are intersected.
- Restrictions on the same hierarchy are unioned.
atoti.tables.Tables.restrictions, cube restrictions have no impact on tables:
Added in version 6.2.1: A restriction can also be defined on a whole hierarchy with Adding Iris with that role only, so that no other restriction is unioned with it:
atoti.Hierarchy.isin(), granting one member path per branch.
Unlike a restriction on a level, this grants members located at different depths:QuerySession has cubes but no tables so there is nothing to merge cube restrictions with.
However, data cubes have their restrictions merged with the ones from the session’s tables:
See also:
atoti.tables.Tables.restrictions.