TM1 Forum

Posted: **Wed Dec 05, 2012 4:21 am**

Hi All,

We trying to clean up some of the elements that have become obsolete in our system and have decided to move them under a "Legacy" roll up structure.
A rule was then created to analyse the elements & if they only existed in the Legacy Structure, to update it's permissioning to "NONE".
Now the Rule seems to be working, it is updating the READ/ NONE of the particular element. All seems to be going according to plan...

The issue is that now we need to refresh Element Security each time we make changes visible in TM1?

Has anyone done anything similar? Is this the best way to deal with legacy structures / elements? We dont' what to actually delete them for now.

Code is below:

Code: Select all

FEEDSTRINGS;

SKIPCHECK;

# 120926 Assign NONE access to all Products elements/structures that ONLY have Legacy Productss as their ancestor, and belong to no other rollups

# 1st "IF" - check if element has more than 1 Parent...
# 2nd "IF" - check if Element is Ancestor of any other Consolidations other than Legacy Products	

[] = S:
If (ELISANC( 'Product','Legacy Products', !Product) = 1, 
	If (ELISANC( 'Product','PRDINTBUSB', !Product) = 1% ELISANC( 'Product','PMF Product Total', !Product) = 1% 
                ELISANC( 'Product','Total Products', !Product) = 1 % ELISANC( 'Product','Systems Products', !Product) = 1 %
                ELISANC( 'Product','Future Products', !Product) = 1,
    'WRITE', 'NONE'), 
'WRITE') ;

#FEEDERS;

Posted: **Wed Dec 05, 2012 5:40 am**

First suggestion is that you could re-write the rule to be more efficient. Also, your comments are a bit misleading as the first IF doesn't "check if element has more than 1 Parent..."

Code: Select all

[] = S: If ( ELISANC( 'Product','Legacy Products', !Product) = 1 & ELPARN ( 'Product', !Product ) = 1, 'NONE', 'WRITE');

The assumption is that if a product has more than one parent (ELPARN > 1) then it is still a member of a valid hierarhcy and requires a not-NONE permission.

Second suggestion is to stop doing it in rules and do it in TI after your metadata refreshes and then run a security refresh at the end of that cycle. You can easily replicate the rule logic as TI logic. The reason for my suggestion is that unless you have a really fast-moving hierarchy then you don't need rules to dynamically update the security when you need to have a TI update the structure anyhow. All that FEEDSTRINGing and ELISANCing is a bit of an overhead you could probably eliminate at no loss.

TM1 Forum

Adding Rule to Element Security to change Permissions

Adding Rule to Element Security to change Permissions

Re: Adding Rule to Element Security to change Permissions