Apr 15 2015

    Things you might not know about TM1 Security – Part 1

    Have you ever wondered what the ReadOnlyUser field in the }ClientProperties  cube actually does?  This is a numeric property that takes Boolean values of either 1 (true) or 0 (false).  This property has been around at least since v9 and probably even before. It isn’t used very often (or even as often as it actually […]

    Have you ever wondered what the ReadOnlyUser field in the }ClientProperties  cube actually does?  This is a numeric property that takes Boolean values of either 1 (true) or 0 (false).  This property has been around at least since v9 and probably even before. It isn’t used very often (or even as often as it actually should be) and therefore most TM1 developers and administrators aren’t even aware of its existence or what it exactly does.  This post will address this knowledge gap. The purpose of ReadOnlyUser is (presumably) to support licensing modes where a viewer/reporter/consumer only/read-only user type is stipulated.  

    ReadOnlyUser acts as an “overlay” to normal TM1 role-based security conferred by group membership in the }ClientGroups cube.  Any non-admin user with a value of 1 in the ReadOnlyUser property will be limited to read access to cubes even if they would otherwise be conferred write or higher via group membership.  In certain scenarios, this is actually very useful functionality as it allows groups that have write access to cubes to be re-used for read-only users as opposed to requiring an entire 2nd set of groups with otherwise identical privileges but read on cubes not write.  For some models, this can be quite a time and effort saver.  

    Another potential use might be to selectively lock certain users from data access or lock all users on completion of a planning cycle or during a “changes lockout” period. If ReadOnlyUser is used then it can simplify checking licensing compliance for read-only user types as opposed to checking the cumulative effect of all group memberships per user on all cubes to determine the effective read user vs. write user status.  This is probably the reason the feature was created. However, for developers and administrators who are unaware of this feature, this has been known to cause some security trouble-shooting nightmares, as the cube viewer UI has never been updated to take the ReadOnlyUser security overlay into account.  Thus if a user’s cumulative group membership would otherwise be write for a cube then a view of leaf cells in the cube still displays as white (and editable!) despite the user being read-only.  

    An attempt by the user to update a cell will be met with a generic “data entry failed” error message.  If anyone wants to report this UI bug (still there as of 10.2.2) then please feel free.  Otherwise, this is just something to be aware of and save you pulling some hair out when you come across this.

    Related content

    Loading related content