Things you might not know about TM1 Security – Part 1

Apr 15. 20152 min read
Francisco Santos

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 it’s 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 a 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 lock out” 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.
Tagged , ,

KEEP READING

  • Francisco SantosApril 29, 2016 Anti-virus scanning software and TM1 Or have you ever sought to mitigate or prevent virus-scanner related performance issues by ordering scanning exceptions only to have your windows admin or security team scoff at you and […]
  • Francisco SantosMay 8, 2016 Things you might not know about TM1 security – Part 2 There’s more to security than read, write and none although for most intents and purposes these are the only modes that matter from an end user perspective.  However, for object security […]
  • Scott WiltshireAugust 21, 2018 The (increased) importance of attributes in Planning Analytics The importance of attributes in PA Attributes have always been very useful when developing a TM1 model but until now have never been an essential component of development. With Planning […]