TM1 Forum

Hi All,

I have a fairly large dimension with about 10,000 n-elements. Each of these has a specific attribute which is used elsewhere within TI processes and rules.

Since the attribute is very important, it is not to be changed by any user, only the ADMIN user.

However I have noticed that despite setting security for all Client Groups within the }ElementAttribute_Dimension control cube, to READ, it reverts back to WRITE after I save the change, meaning the user can still change the attribute via a DBRA formula on a spreadsheet.

I have read that there maybe a conflict around the fact that the cube this dimension belongs to requires users to have WRITE access but I am a little perplexed as to whether this maybe a bug or something else.

If any of you have seen this before I would be grateful for some insights.

BTW - using normal editors to update security

Thanks
Ajay

Two things spring to mind, first is that it's possible you have a rule on your }Cube_Security cube. More likely is that you've given users 'WRITE' access to the dimension. Give them 'READ' access to the dimension instead (but write access to the elements within the dimension. This is the default unless you set up element security on the dim).

Martin

Hi Martin

No joy I'm afraid.

There is no rule on the }Cube_Security cube, and when I gave users the READ access they were still able to change the attribute through the DBRA formulae

Ajay

Ajay wrote: There is no rule on the }Cube_Security cube, and when I gave users the READ access they were still able to change the attribute through the DBRA formulae

I'd be inclined to check (and if necessary change) the access by browsing the }Cube_Security cube itself. It's possibly some funkiness with the GUI.

After that I'd reboot the server; I've found that sometimes access changes don't stick until it's freshly loaded, but it tends to be an intermittent issue. Running a TI calling the SecurityRefresh function may be enough, but a reboot would be safer.

I haven't encountered an issue where users who really do have only read access to the attributes cube can write to it, though bear in mind that TM1 uses the least restrictive model; no group should have write access to the cube. (The Admin group has it implicitly regardless of what you set (or try to set) the access to.)

Thanks Alan

Unfortunately, it didn't work.

So I've had to put a work around in place using a secondary dimension which holds the untouchable attribute value which is used in the Rules and TI that are dependent upon it.

Thanks all for the assitance

Ajay