Security Control cubes

[appleglaze28]

Hi Guys,

Just a question I wrote a rule to change the security of dimension base on the attribute of that dimension. I have a process that add elements on that dimension. How come when I check the cube, the cube's rights is update but not the actual access to those elements? The only time it updates is when I open Element Security tick on of the security setting and Save it and then open Element Security.

I tried taking out the rules out of the control cube for the security of that dimension...but it still retains a "NONE" rights for the users.

Code: Select all

Below is the rule I wrote for the security cube

Code: Select all

[{'ADMIN','SecurityAdmin', 'DataAdmin'}] = S: IF(DB('}ElementAttributes_base_worksheet_so_number',!base_worksheet_so_number,'so_approval')@='',STET,CONTINUE);
[{'ADMIN','SecurityAdmin', 'DataAdmin'}] = S: IF(DB('}ElementAttributes_base_worksheet_so_number',!base_worksheet_so_number,'so_approval')@<>'',STET,CONTINUE);
['}tp_Everyone'] = S: IF(DB('}ElementAttributes_base_worksheet_so_number',!base_worksheet_so_number,'so_approval')@='','WRITE','WRITE');
	
[{'Accounts Payable - S','Commission','Accounts Payable - M'}]= S: IF(DB('}ElementAttributes_base_worksheet_so_number',ELPAR('base_worksheet_so_number',!base_worksheet_so_number,1),'so_approval')@='No Approval','',CONTINUE);
[] = S: IF(DB('}ElementAttributes_base_worksheet_so_number',!base_worksheet_so_number,'so_approval')@<>'','READ',CONTINUE);
[] = S: IF(DB('}ElementAttributes_base_worksheet_so_number',!base_worksheet_so_number,'so_approval')@='Approved','READ','WRITE');

[Steve Vincent]

first up you need to ensure you are feeding the rules. i had no end of issues with security via rules and eventaully gave up, mainly over problems with feeding. second thing is you need to ensure security is refreshed if you have made changes to a dimension, especially when maintaining the security by rules.

i found the latter the biggest issue as the rules where too heavy on the cube, it stalled the server for far to llong so i replaced all the security maintenance with TIs.

[qml]

Steve,

You only need to feed your string cube (and security cubes are string cubes) if you use SKIPCHECK and you want to work with zero-supressed views. I wonder why you might need it in the first place. I would just write such rules with no SKIPCHECK and no FEEDSTRINGS and no FEEDERS.

And yes, you need to run SecurityRefresh after metadata updates if your security is rule-based.

[lotsaram]

first up you need to ensure you are feeding the rules. i had no end of issues with security via rules and eventaully gave up, mainly over problems with feeding. second thing is you need to ensure security is refreshed if you have made changes to a dimension, especially when maintaining the security by rules.

i found the latter the biggest issue as the rules where too heavy on the cube, it stalled the server for far to llong so i replaced all the security maintenance with TIs.

I use rules for element security all the time and have never had any issues, there is no need to use skipcheck, feeders or feedstrings in security cubes (UNLESS you use ViewConsolidationOptimisation=T in the config file, in which case things do get a whole lot more complicated ...) Just remember
as qml has mentioned that you need to do a security refresh after dimension updates to the dims using rule based security if new elements have been added (or attributes changed that affect security etc.) That is probably all the OP's problem is.

[Steve Vincent]

I use rules for element security all the time and have never had any issues, there is no need to use skipcheck, feeders or feedstrings in security cubes (UNLESS you use ViewConsolidationOptimisation=T in the config file, in which case things do get a whole lot more complicated ...)

From memory we did have that set and we certainly required the cubes to work when zero suppressed, hence the feeders. The security was such that there was a lot of NONE cells and not being able to zero suppress was a total pain and it was that combination that caused a security refresh to take about 10 mins - 9.5mins too long for the customer, hence the change to TI driven security.

[appleglaze28]

I removed the rules in security cubes...now my dilema is...everytime i add new elements in that dimension its always none...so i have to do it manually on the TM1 Dimension security. How can I reset it to having all new added element be on a "WRITE" security.

[Alan Kirk]

I removed the rules in security cubes...now my dilema is...everytime i add new elements in that dimension its always none...so i have to do it manually on the TM1 Dimension security. How can I reset it to having all new added element be on a "WRITE" security.

I don't think that's offered as an option. However a (relatively) easy way around that would be to create a TI which iterates through the dimension, adding write access where the access is none. Run that after you update the dimension and you don't have to waste time setting the access manually.

[Michel Zijlema]

I removed the rules in security cubes...now my dilema is...everytime i add new elements in that dimension its always none...so i have to do it manually on the TM1 Dimension security. How can I reset it to having all new added element be on a "WRITE" security.

I don't think that's offered as an option. However a (relatively) easy way around that would be to create a TI which iterates through the dimension, adding write access where the access is none. Run that after you update the dimension and you don't have to waste time setting the access manually.

If you don't need any element security on the dimension anymore you can delete the }ElementSecurity_* cube(s) for the regarding dimension(s) from the data directory. When there is no }ElementSecurity cube the default security assignment is WRITE.

Michel

[Alan Kirk]

I removed the rules in security cubes...now my dilema is...everytime i add new elements in that dimension its always none...so i have to do it manually on the TM1 Dimension security. How can I reset it to having all new added element be on a "WRITE" security.

I don't think that's offered as an option. However a (relatively) easy way around that would be to create a TI which iterates through the dimension, adding write access where the access is none. Run that after you update the dimension and you don't have to waste time setting the access manually.

If you don't need any element security on the dimension anymore you can delete the }ElementSecurity_* cube(s) for the regarding dimension(s) from the data directory. When there is no }ElementSecurity cube the default security assignment is WRITE.

Michel

You're right, I should have mentioned that option. I assumed that some of the existing elements were still secured. Obviously Michel's solution will only take effect after a server restart.