You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some tm1py functions like get_message_log_entries have the @require_admin wrapper, but the rest call made by the function only requires OperationsAdmin level on the server. I think we should add an is_operations_admin connection property similar to is_admin and modify any functions that only require OperationsAdmin to test that property instead. It's possible there are functions that would be accessible to a DataAdmin as well, but I don't have an example right now.
Taking this a step further, many security functions only require SecurityAdmin within TM1. Perhaps we need an is_security_admin property as well that would be True when the client is either a full admin or is in the SecurityAdmin group. I can imagine integration options with access request systems where I give them a python script to execute to make client/group changes and I'd only want that client to be a SecurityAdmin instead of full admin.
I propose 3 new connection properties to complement is_admin: is_operations_admin, is_data_admin, is_security_admin. A full admin would have True for all 4 properties for TM1py purposes, regardless if they're in the groups on the TM1 server. The SecurityAdmin and DataAdmin groups don't play nice together anyway.
I'll hopefully start some work on this in the next couple weeks.
The text was updated successfully, but these errors were encountered:
Here's a list of TM1py functions currently with the @require_admin decorator and what level of admin access is required by the server to complete the action.
Some tm1py functions like
get_message_log_entries
have the @require_admin wrapper, but the rest call made by the function only requires OperationsAdmin level on the server. I think we should add anis_operations_admin
connection property similar tois_admin
and modify any functions that only require OperationsAdmin to test that property instead. It's possible there are functions that would be accessible to a DataAdmin as well, but I don't have an example right now.Taking this a step further, many security functions only require SecurityAdmin within TM1. Perhaps we need an
is_security_admin
property as well that would be True when the client is either a full admin or is in the SecurityAdmin group. I can imagine integration options with access request systems where I give them a python script to execute to make client/group changes and I'd only want that client to be a SecurityAdmin instead of full admin.I propose 3 new connection properties to complement
is_admin
:is_operations_admin
,is_data_admin
,is_security_admin
. A full admin would have True for all 4 properties for TM1py purposes, regardless if they're in the groups on the TM1 server. The SecurityAdmin and DataAdmin groups don't play nice together anyway.I'll hopefully start some work on this in the next couple weeks.
The text was updated successfully, but these errors were encountered: