User access to cells

[wimgielis]

Hello all,

Image a user complains that he/she does not have read or write access to a certain cube cell. Or the user has access but shouldn't have.

What does the community think about a function that, when given:

• a cube name
• a tuple of dimension elements
• a user

, can work out the specific rights of the user to that cell ?
I would typically think this is useful for ad hoc analyses, rather than large sets of users to multiple cells/slices, etc.

Then again, we know that it takes time to do this manually:

• rights go by group, not by user, so for a user we "add up" the rights of the group memberships
• rights are there for cubes, dimensions (hierarchies), elements, cells
• cell security can behave differently depending on the settings by cube (most restrictive, ...)
• users can be forced as disabled or read-only
• there are Capabilities that come into play, rules-calculated cell or not, consolidated or not, a hold can be applied, locks, reservations, security overlay, etc.

See: https://www.wimgielis.com/tm1_cellchange_EN.htm

I find it a hassle to check this, or test when developing models, such that a function might be useful.

The best would be some verbose output ==> the user has Write/Read/None access because:

• at cube level, we have ... by group and hence, the result is ... for the user
• at dimension level, we have ... by group and hence, result is ... for the user
• at elements (plural !!!) level, we have ... by group and hence, result is ... for the user
• cell level, we have ... by group and hence, result is ... for the user
• the user is not disabled, not ReadOnly
• etc.

What do you think ? Reading data from the control cubes would already be a good start, then extracting the right information and bringing it all together to a summary output. Important is that the developer needs to master both Python and the TM1 security model and needs the necessary time ;-) Maybe someone in the community already did this exercise, maybe not in Python but similar and still exploiting the TM1 REST API ?

[MariusWirtz]

I think using TM1py with impersonation could be a real shortcut to evaluate effective permissions on the user level.

from TM1py import TM1Service

tm1_params = {
    "address": "",
    "port": 12354,
    "user": "admin",
    "password": "apple",
    "ssl": True
}

with TM1Service(**tm1_params, impersonate="Wim") as tm1:
    cellset = tm1.cells.execute_mdx(
        mdx="SELECT {([d1].[e1], [d2].[e1])} ON 0 FROM [c1]",
        element_unique_names=False,
        cell_properties=["Updateable"])

    print(cellset)

[MariusWirtz]

@wimgielis, what do you think about this approach?
We might want to wrap this idea in a nice and easy-to-use TM1py function with the arguments you suggested above. Would you like to do a Pull Request?

[wimgielis]

Hello Marius,

I will play around with what this can give us. If it's a good output regarding what the user can or cannot do, then I am happy to take it. I would also see an interest in kind of an overview of the effective permissions. Depending on what comes out after impersonation, we can take that as a shortcut and alternative. Thanks.

[MariusWirtz]

OK. To understand the updateable property, use the extract_cell_updateable_property function from the TM1py.Utils module

tm1py/TM1py/Utils/Utils.py

Line 1166 in 6105399

def extract_cell_updateable_property(decimal_value: int, cell_property: CellUpdateableProperty) -> bool:

[wimgielis]

Hello Marius,

I did some testing on this, thanks for the information. It's nice that we can read and interpret the cell properties !
With an admin user, I can get the results I expect, except for a consolidated cell in a view where "Consolidated" gives me False. I could not explain that False.
Then, when I then do an impersonation to the exact same cells where indeed I know that the user will not have rights because the one group he belongs to, does not have read access to the cube. Then (in Visual Studio Code) I get an TM1pyRestException: ObjectSecurityNoReadRights. There is definitely no access to the cell but is this exception than what I should expect from the test ? Should there be a kind of Try Catch construct ? "DSM" is the user with read access on the element DSM in a certain dimension, but other than that, no rights at all in this test TM1 model.

I was able to use the extract_cell_updateable_property, thanks:
print(Utils.extract_cell_updateable_property(258, CellUpdateableProperty.CELL_IS_NOT_UPDATEABLE))
print(Utils.extract_cell_updateable_property(258, CellUpdateableProperty.SECURITY_RESTRICTED))
Definitely more testing to be done but it looks promising. However, when we know that SECURITY is restricted, I think it would be good dig deeper to see where the restrictions come from. Hence, by group and adding up for the user. That's a whole other story I'm afraid but saving time to not create the different views in the control cubes and check ourselves.