Join / Log in Explore BA Products
Acutally you don't need to create groups in CA since your data is hosted inside TM1. I'm speaking about creating native TM1 groups, which will prevent users from seeing other users data.You can build a simple process that does the following : - loop thru all items of }Clients dimension (using a WHILE .. END or a subset of the }Clients dimension as a source of the process)- for each one do an addGroup of the user name (call it something like User_<userName> to distinguish from the "regular" groups)- do an assignClientToGroup of the user to this new groupThen you'll have to manage security along the employee dimension in your data cube, which can be done easily with an attribute linking the client and the employee in the same process, or a secondary process, or in a rule.We have this logic in place for several applications, up to 2000 users (going on 4000).Using one group per user can seem counter-intuitive but on complex applications is actually far less complicated than using module / entity / domain / whatever groups which can't be finely tuned (or you might end up with hundreds of groups anyway).Cheers, Laurent
Hello Ann, That can be done but in this case you could do it directly in the dimension security cube instead.
I would also avoid using rules on security objects since you'd need to run a SecurityRefresh with each structure change, which depending on the size of the model can be painful.In my experience using one group per user allows for a very fine approach of the security, especially on systems with multiple and complex hierarchies on big dimensions. There is no rule of thumb or best practice so, hey, why not ? Cheers, Laurent
Laurent:I am sorry I was not clear. With the approach I suggested, Security Refresh is only necessary ONCE, when you save the rule on the Cell Security cube. You do not have to do it after that one time.I have not recently tried to put rules on the Element Security cube, but I suspect you will potentially run into one or both the following problems:1) The trick of using the TM1USER function to detect the person who is logged in and adjust security in depends on TM1USER being reevaluated in real-time. I believe (but you should verify) that rules on the Element Security cube (unlike those on Cell Security) are evaluated just once - when they are saved. TM1USER at this time will evaluate to the Id of the rule writer and stay there. In other words, element security will NOT adjust in real time as we want. 2) If my hypothesis in #1 is incorrect you will run into the Security Refresh issue you pointed out, which I agree is not realistic.I agree that creating security groups for each user is a viable approach and automating their creation makes it easier. However keep in mind that there can be a performance cost to having too many security groups, so depending on other aspects of your model it can be good to know what options are available to you.Regards,AG
Cell security is always dynamic, even after a dimension update, and does not require a SecurityRefresh. Only object level security requires a refresh when using rules.