Element Security

[Mithun.Mistry1103]

Hello

Some advise if possible please

I have given write permissions on a dimension within the security attributes to solve the "the view is corrupt/user does not have permission" error on app web.

But prior to that, it worked and a user was able to commit data and that was confirmed when I looked at the transaction log.

Why would that be the case, surely if the issue was the security attribute not having write permissions, it should not work completely instead of "working one min " and "not working the next".

Thanks

Regards

Mithun

[qml]

Surely something must have changed for the user to lose access. No one here will be able to tell you exactly what that was without more information. I assume when you say 'I have given write permissions on a dimension within the security attributes' you mean that you amended dimension security (not to be confused with element security) in such a way as to give the user write access to the dimension. Normally you do not need to do this unless you've introduced dimension security in the first place (which has very limited use anyway and in most TM1 deployments should not be touched at all). So maybe that's what's changed when someone started playing with security settings?

[Mithun.Mistry1103]

Hello qml

Surely something must have changed for the user to lose access

see thats very strange because I am the one who deals with the security so I am sure there hasnt been any changes in security. yes the write permission is on the security attribute cube for the dimension.

Again the sdecurity settings that were changed wer the one mentioned below, which was giving write permissions.
Could this just be a red herring where the security settings were fine one minute and then not working the second?

Thank you for your time and efforts

Mithun

[AmbPin]

Only thing I can think of is that if your security is rule driven it might not actually have been applied until now. Did you restart the server recently?

[qml]

yes the write permission is on the security attribute cube for the dimension

Unfortunately, you are using very ambiguous terminology, which makes it hard for me to understand what exactly you mean.
Do you mean that you have:
- element security (settings stored in an }ElementSecurity_[dimension] cube)
or
- dimension security (settings stored in the }DimensionSecurity cube)?

Please can you write exactly what security setup you have and how you maintain it (which interface is used, whether there are rules etc).

[Mithun.Mistry1103]

AmbPin

No it isnt rule driven, we lock up the nodes that are not current with no WRITE security issued. For the current, we Write and UNLOCK that node so users can enter into cubes using that dimension for that unlocked element.

qml - Sorry for using ambiguous terminalogy, it is the }ElementSecurity_Dimension and I have shown below how it is set up

Apologies for going on about this, i want to know the reason so if we do get this issue, I have a solution and will know what to do to solve it.

[tomok]

Security in TM1 is a combination of all the security settings for a particular cube. If this is Contributor it is further complicated by your approval dimension. Look at ALL the following cubes and make sure they ALL have WRITE for the intersections in question:

}CubeSecurity
}DimensionSecurity
}ElementSecurity_XXXX (where XXXX is the name of every dimension in the cube)

If there isn't a WRITE in all of these then you will not be able to write. If any of these cubes are missing then you can ignore as the default is WRITE if no security is set.

P.S.
I forgot about CellSecurity. If you have one of those for the cube in question make sure it has WRITE too.