TM1 Forum

Is there a way to restrict access to available aliases?

I've tried element security on the }ElementAttributes dimension and it didn't work...

Thanks,

Dan

dan.kelleher wrote:Is there a way to restrict access to available aliases?
I've tried element security on the }ElementAttributes dimension and it didn't work...

No, we've been down that path too with our HR model. (Employee names, specifically.) Unfortunately it doesn't appear to be possible but I'd be happy to be proven wrong on that. The only workaround was to load what would normally be attributes/aliases into a lookup cube. Useless for cube viewer but OK for Excel reports / websheets.

Thanks Alan,

I think the reporting side will use BI so I believe we can get away with your proposed solution.

Thanks,

Dan

As a TM1 Developer for almost 2 decades, I tend to make assumptions on how TM1 behaves...

Well yesterday I was helping one of my users with a dimension attribute and to my complete surprise the user had write access and was able to update the attribute
Besides having a scooby-doo moment or a WTF moment for those of you who don't get the scooby-doo experience, this was extremly concerning to me

Since when can a user update an attribute?????
We are currently using 9.5.1 and I never remember in any previous version that users had write access by default to do this
Back in the old days (pre Version 7) I used look-up cubes but once attributes came onto the playing field I personally have never looked back and I do a tremendous amount of development using them
I have done so much development with attributes that the applications are at risk if a user can make changes

So I rolled up my sleeves to try and figure this one out...
With some trial and error making assumptions that if I just change the write access on the }ElementAttributes_DimensionName to READ this would solve the problem
No go...
Next I tried setting up cell security within the }ElementAttributes_DimensionName Cube
Again, no go...

I then took the TM1 service down to remove the cell security cube and then I called it a night to attack it in the morning

With a fresh start this morning I took a deep breath and thought about it since based on my experience there is no way that TM1 would have such a gaping security hole in it

While dreaming about it last night, I thought... what would happen if you changed the write access at the top of the house... meaning at the dimension level instead of on the specific dimension
Well, go figure... I right-clicked on Dimensions... Security Assignments and there they were... all those little WRITE buggers
I changed all of them to READ for all users

I then logged in as a user and tried to update an attribute, and low and behold the user is now restricted... Phew!
I also verified that the user still has write access to enter data within the appropriate intersection

So Alan, I believe I may have proven you wrong

It actually makes perfect sense since the default for all TM1 objects is WRITE
However, having to make this change at the Dimension level doesn't quite compute but the fact that it's now fixed is really all that matters

Solanna

Good call. This something to remember. I can't remember the last time I came across a model that didn't use attributes in some form or another,

Jim.

Solanna wrote:As a TM1 Developer for almost 2 decades, I tend to make assumptions on how TM1 behaves...

Well yesterday I was helping one of my users with a dimension attribute and to my complete surprise the user had write access and was able to update the attribute
Besides having a scooby-doo moment or a WTF moment for those of you who don't get the scooby-doo experience, this was extremly concerning to me

Since when can a user update an attribute?????
We are currently using 9.5.1 and I never remember in any previous version that users had write access by default to do this
Back in the old days (pre Version 7) I used look-up cubes but once attributes came onto the playing field I personally have never looked back and I do a tremendous amount of development using them
I have done so much development with attributes that the applications are at risk if a user can make changes

So I rolled up my sleeves to try and figure this one out...
With some trial and error making assumptions that if I just change the write access on the }ElementAttributes_DimensionName to READ this would solve the problem
No go...
Next I tried setting up cell security within the }ElementAttributes_DimensionName Cube
Again, no go...

I then took the TM1 service down to remove the cell security cube and then I called it a night to attack it in the morning

With a fresh start this morning I took a deep breath and thought about it since based on my experience there is no way that TM1 would have such a gaping security hole in it

While dreaming about it last night, I thought... what would happen if you changed the write access at the top of the house... meaning at the dimension level instead of on the specific dimension
Well, go figure... I right-clicked on Dimensions... Security Assignments and there they were... all those little WRITE buggers
I changed all of them to READ for all users

I then logged in as a user and tried to update an attribute, and low and behold the user is now restricted... Phew!
I also verified that the user still has write access to enter data within the appropriate intersection

So Alan, I believe I may have proven you wrong

Er, no, actually.

I believe that the original discussion was about restricting access to allow Group A to see the aliases of particular elements but not the aliases of other elements, Group B to be able to see the aliases of elements in their own area, and so on.

As I mentioned, the most common use of this is in HR models where you may want members of Group A to be able to see the employee names of only those in their own department, Group B to be able to see only their own ones, and so on.

Useful as your demonstration was... it's an entirely different subject.

(Incidentally, I've always found that setting the access to READ on the attribute cubes (except for the ones that I want them to be able to change) does prevent users from writing to them.)

dan.kelleher wrote:Is there a way to restrict access to available aliases?

I've tried element security on the }ElementAttributes dimension and it didn't work...

Thanks,

Dan

Alan,

Unless you are reading a different post or you have the ability to read into Dan's mind... I don't see anything in regards to his original post mentioning different groups having access to Aliases

His post was very simplistic and your response was just as simplistic
So given the overall simplistic nature of the post/response I believe my post is actually quite accurate in regards to proving you incorrect
Certainly it was only in jest... thus the wink

However, unlike yourself I do not spend several hours each week on the TM1 Forum on a regular basis so I would assume you are probably talking about another post that is somewhere out there in the bowels of the forum

All the best,

Solanna

Solanna wrote:

dan.kelleher wrote:Is there a way to restrict access to available aliases?

I've tried element security on the }ElementAttributes dimension and it didn't work...

Thanks,

Dan

Unless you are reading a different post or you have the ability to read into Dan's mind... I don't see anything in regards to his original post mentioning different groups having access to Aliases

His post was very simplistic and your response was just as simplistic
So given the overall simplistic nature of the post/response I believe my post is actually quite accurate in regards to proving you incorrect
Certainly it was only in jest... thus the wink

However, unlike yourself I do not spend several hours each week on the TM1 Forum on a regular basis so I would assume you are probably talking about another post that is somewhere out there in the bowels of the forum

You would assume incorrectly. Read Dan's post.

I've tried element security on the }ElementAttributes dimension

Element. Security.

Element. Attributes. Dimension.

Why exactly would anyone be trying to set element level security on a dimension, any dimension, unless it was to restrict access to different elements by different user groups?

It's not simplistic, just simple. The fact that you've gone flying off onto unrelated tangents about cell level security and what have you doesn't prove a thing relating to the original posts, because you're talking about something completely unrelated.

And I reiterate, taking the "simplistic" approach of setting read access to the element attributes cubes WILL stop end users writing to them, without all of the fluff and drama above.

Alan,

Drama, really?????

Given that you are the most dramatic of anyone on this forum, I find your comment quite amusing...

As an FYI, before I found this post I had actually tried to find other posts out there relating to Dimension Attribute security with little luck
However, I did find a post that was referencing the }ElementAttribute_DimensionName dimension which seemed like the reasonable place to go to set security since the whole point was to set up security on the attribute not on the dimension... I believe the poster had similar results in that by setting access on that dimension it would still allow write access to the attribute
Do you agree in theory that this is where the security should be set and not at the Dimension level since it's attribute security?

Since Dan was looking to restrict access to aliases, and was attempting this within the }ElementAttribute_DimensionName dimension it seemed to me that he was trying to set security on the attribute
So yes maybe I did misread his post but how you got multiple Groups out of his two sentences is actually quite an amazing talent since he never asked that
But given the amount of time you spend on this forum, you obviously have more practice at reading between the lines than I do

Keep up the good work!

Solanna

Solanna wrote: Drama, really?????

Given that you are the most dramatic of anyone on this forum, I find your comment quite amusing...

Glad to entertain you. Perhaps you can have a dream about it tonight.

Solanna wrote:As an FYI, before I found this post I had actually tried to find other posts out there relating to Dimension Attribute security with little luck
However, I did find a post that was referencing the }ElementAttribute_DimensionName dimension which seemed like the reasonable place to go to set security since the whole point was to set up security on the attribute not on the dimension... I believe the poster had similar results in that by setting access on that dimension it would still allow write access to the attribute
Do you agree in theory that this is where the security should be set and not at the Dimension level since it's attribute security?

No, I don't. It's perhaps one way of doing it. But as I have said, twice now, if you want to ensure that users can't overwrite attributes, just set Read access to the Element Attributes cube. That's it, no muss, no fuss. You said that you tried that in your original post, but whatever you tried clearly didn't work correctly since that is exactly the way I've been doing it for over half a decade and it still works in 9.5.2. If a user has only read access to a cube (and attributes including aliases ARE stored in a cube, just as any other data is), then they obviously can't write to it.

I don't actually mind being told I'm wrong when I am, and that has happened. I mind being told that I'm wrong when it's about something completely different, by someone who has an error like that in their own post.

Solanna wrote:Since Dan was looking to restrict access to aliases, and was attempting this within the }ElementAttribute_DimensionName dimension it seemed to me that he was trying to set security on the attribute
So yes maybe I did misread his post but how you got multiple Groups out of his two sentences is actually quite an amazing talent

Yes, it's a talent called "literacy". If someone didn't want to set up different levels of security, which would imply (OK, it's two talents, literacy and logic) that one group has a particular type of access to a range of elements, another group has a different type of access (or no access) to a range of elements, then why would they bother setting up element level security on a dimension? Different levels of access imply, pretty clearly, that more than one security group is involved. It's not always necessary for every last detail to be spelt out for the question to be clear.

Solanna wrote:since he never asked that
But given the amount of time you spend on this forum, you obviously have more practice at reading between the lines than I do

That's the second time you've had a sarcastic dig at that. The first time I let it slide, this time I won't. Yes, I do spend a fair amount of time here. As one of the admins, I do feel a certain obligation to try to to help, support and encourage the broader TM1 community. I've probably helped quite a few over the years. How many have you helped? Oh, 23 posts. Must be a real boon. So if you want to have a go at me for being on here a fair bit? Go right ahead. I know who the comment reflects worse on.

I'm not being funny but this has gone far enough. Alan you should know the forum policies better than anyone. Any more posts on this thread regarding this dispute and I'm sure either I or another member of the admin team will delete them. Alan did make a point about helping people. This isn't helping anybody.