Page 1 of 1
Can TI create a private subset?
Posted: Fri Nov 18, 2011 6:32 pm
by pmakulski
This question was asked here
http://www.tm1forum.com/viewtopic.php?p=3412 , but it was back in 2009 and the answer was no.
Is it still no, after a few years and versions?
I'm having some trouble with a dynamic subset, which I don't yet understand.
The Public subset looks up the user in the client table and returns a position in the org hierarchy. Then, it reutrns all items under that hierarchy point.
Code: Select all
{TM1DRILLDOWNMEMBER(
{FILTER( {TM1SUBSETALL([BudgetOrg])} ,
[BudgetOrg].CurrentMember.Name =
[}ElementAttributes_}Clients].(StrToMember("[}Clients].[" + USERNAME +"]"),[}ElementAttributes_}Clients].[FlashOrg])
)}
, ALL, RECURSIVE )}
It seems to work fine most of the time, particularly on the browser. It doesn't seem to work in perspectives (for nonadmin users).
I was tempted to make a specific private subset for each user, but that doesn't seem possible. I don't see a TI process to unpublish, or to create a subset as private.
Ideas?
9.5.2 Excel 2003
Re: Can TI create a private subset?
Posted: Fri Nov 18, 2011 7:04 pm
by qml
It's enough to copy that subset's *.sub file to the correct user subfolder in the data directory. Then you can simply delete the public subset. It doesn't even require a server restart - the private subset should be available as soon as that user logs on. This is one of the solutions proposed in the thread you've linked and is very easy to implement as a workaround for the lack of a scripting method of creating private subsets.
Re: Can TI create a private subset?
Posted: Fri Nov 18, 2011 10:58 pm
by pmakulski
Not quite as easy to implement as you might think.
I don't have access to the Production data folder. Which means I would need to engage IT, which means, abandon all hope.
Re: Can TI create a private subset?
Posted: Fri Nov 18, 2011 11:25 pm
by qml
Any service account that TM1 is using by default has to have full access to that server's data directory. As a result you can execute any changes in the data folder from a TI process. Just use the ExecuteCommand function to run any DOS file operations you like (copy, move, del etc).
Re: Can TI create a private subset?
Posted: Sat Nov 19, 2011 8:04 pm
by Alan Kirk
Just to expand on QML's answer a little, if you have one of those absurd IT departments which don't let you access
any folders that the server can see (which effectively stops an admin being an admin, but I digress) you can generate the DOS batch file that moves the file through TI as well. Wim posted a useful primer on how to do that in
this thread.
Re: Can TI create a private subset?
Posted: Sun Nov 20, 2011 7:37 am
by Harvey
When a TI runs, it runs as administrator inherently, hence you can only create public objects.
The idea of private subsets is for the users create them for themselves. If someone else could create subs on their behalf, it would be outside the security "philosophy" of TM1.
All users can access public subsets, however, so why not create a *public* subset for each user, instead of a private one? If you name them sensibly, this may be the path of least resistance. If your element security is set up correctly, you should have no issues with users seeing each other's data. You can then use the Application folder (it's always a good idea to do this anyway) to link to the relevant subsets, reports, etc for each user group.
The information on copying the subset in the file-system is correct, but may not suit your exact situation. It's probably you best option, though, to create some ExecuteCommand function calls that copy the created subset into the user's private folders. It's also a bit of a security loophole, so make sure this is what your client really wants you to do!
The last option would be to write some code using the TM1 API. Unlike TI, the TM1 API runs in a specific user context, and can create private subsets. However, you need the password of the user to programmatically "log in" before you can do so.
Again, might not suit your needs, as you can't retrieve the user's password with the API -- again, that would be a serious security loophole. Worth looking at, though.
As an experienced software developer and old-skool API expert, I can advise further on this option if you decide to look into it, and could probably whip up some code for you, depending on your software environment. Send me a PM if you want to talk about that.