restricting access to aliases

Post Reply
dan.kelleher
Community Contributor
Posts: 127
Joined: Wed Oct 14, 2009 7:46 am
OLAP Product: TM1
Version: 9.4
Excel Version: 11
Location: London

restricting access to aliases

Post by dan.kelleher »

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
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: restricting access to aliases

Post by Alan Kirk »

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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
dan.kelleher
Community Contributor
Posts: 127
Joined: Wed Oct 14, 2009 7:46 am
OLAP Product: TM1
Version: 9.4
Excel Version: 11
Location: London

Re: restricting access to aliases

Post by dan.kelleher »

Thanks Alan,

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

Thanks,

Dan
Solanna
Posts: 35
Joined: Thu May 29, 2008 11:20 pm
OLAP Product: TM1
Version: 9.5.2 to 10.2
Excel Version: 2007 - 2013
Location: Redondo Beach, CA USA

Re: restricting access to aliases

Post by Solanna »

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
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: restricting access to aliases

Post by jim wood »

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.
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: restricting access to aliases

Post by Alan Kirk »

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.)
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Solanna
Posts: 35
Joined: Thu May 29, 2008 11:20 pm
OLAP Product: TM1
Version: 9.5.2 to 10.2
Excel Version: 2007 - 2013
Location: Redondo Beach, CA USA

Re: restricting access to aliases

Post by Solanna »

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
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: restricting access to aliases

Post by Alan Kirk »

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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Solanna
Posts: 35
Joined: Thu May 29, 2008 11:20 pm
OLAP Product: TM1
Version: 9.5.2 to 10.2
Excel Version: 2007 - 2013
Location: Redondo Beach, CA USA

Re: restricting access to aliases

Post by Solanna »

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
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: restricting access to aliases

Post by Alan Kirk »

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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: restricting access to aliases

Post by jim wood »

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.
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
Post Reply