TM1 Forum

Hi All,

I have a user with a private default view that he'd like to periodically publish for others to use, preferably by launching a TI process. However, we don't want the view to become the public default view when published - we'd like to give it a different name, such as "John's Default View" which others can then open.

My first attempt at this was to launch a batch script from TI which copied the user's private "Default.vue" as "John's Default View.vue" into the cube's public view folder. However, the temporary subsets being used in the user's private default view did not appear when "John's Default View" was opened by anyone else. It seems that those details aren't carried over when simply copying a .vue file into the public view folder, as they are when actually using the PublishView() function in TI. These are not saved subsets by John that I can find in a "*-subs" folder in his directory to copy - just the selections he made in his default view when he saved it.

Next, I tried an approach where I made a copy of the user's private default view named "John's Default View.vue" in his own view folder, then did a PublishView() on that view file, since I know PublishView() does carry over those selections. This would work, but only if the view were created, the user logged out and back in to make it appear, then the PublishView() command was ran. Otherwise, the TI process would say the view could not be found, despite the .vue file existing in John's directory. This prevents the process from doing what we want in one run. We could have two processes and tell the user to run one, log out, then log back in and run the other... but that's not the most elegant sounding solution.

Does anyone have a solution for this? Thanks in advance for any help.

You've hit on one of the weaknesses in TM1, namely the ability of anyone other than an administrator to share anything with others. The best solution I've been able to come up with for this is to establish a procedure for elevating the user to Admin status so they can publish their view and then removing it. You can do this with a Ti process they can run and then you log it so you can make sure people are behaving appropriately, If you are really paranoid you can have the TI process send you an email every time someone elevates themselves so you can go back to make sure they've un-elevated themselves

One simple solution would be to have John save it as something other than his default view. Then he could happily publish it without issue.

tomok wrote:You've hit on one of the weaknesses in TM1, namely the ability of anyone other than an administrator to share anything with others. The best solution I've been able to come up with for this is to establish a procedure for elevating the user to Admin status so they can publish their view and then removing it. You can do this with a Ti process they can run and then you log it so you can make sure people are behaving appropriately, If you are really paranoid you can have the TI process send you an email every time someone elevates themselves so you can go back to make sure they've un-elevated themselves

We're going to go with this option. Having the access be very temporary, and us logging it and receiving emails when access is granted/removed relieves any major worries. Thanks for the idea.

Its not avaialable in 9.5.2 but in 10.1.1 and higher you can use the PublishView function in a TI.

Also, all you need to do is set their rigths on the cube to Admin. I wouldn't make them temporary server admins to do this. (Just making sure this wasn't the road you were headed, it might be a licensing issue if you did).

PlanningDev wrote:Its not avaialable in 9.5.2 but in 10.1.1 and higher you can use the PublishView function in a TI.

I'm pretty sure that PublishView has been around for a while - in the 9.5.x releases and quite likely even earlier than that. The OP has 9.5.2 in their profile so it should work for him.

PlanningDev wrote:Also, all you need to do is set their rigths on the cube to Admin. I wouldn't make them temporary server admins to do this. (Just making sure this wasn't the road you were headed, it might be a licensing issue if you did).

Correct, I'll just be giving the user admin rights to the cube involved.