TM1 Forum

Hi,

I have a requirement from a set of users: Two users want to be able to share the cube views that they created.
Obviously I can copy *.vue files from one user to the other user in TM1 data folder. But this will not be impacted until I unload the cube, which would take considerable time for big cubes.

Is there an easier or more practical way of achieving the same requirement?

Thanks in advance for replies.

Regards,

You could build a process that would call a script file which would copy the .vue files from one user to another. This would be a complex implementation. I personally have not developed it but have seen it in use. Just an option to look into.

There's been a request on this for a couple of years (such as this one http://forums.olapforums.com/viewtopic.php?f=19&t=266 and I was assured at the time that it was on the radar...)

There are only workaround at this stage. Another one is to make user A an administrator temporarily and publish the view. User B can then see the view and save it as a private view if they wish.

Or slice out to Excel and send that instead.

Martin

mce wrote:I have a requirement from a set of users: Two users want to be able to share the cube views that they created.
Obviously I can copy *.vue files from one user to the other user in TM1 data folder. But this will not be impacted until I unload the cube, which would take considerable time for big cubes.

You don't need to unload the cube. Having the user log out and log back in will be all that's needed when you're talking about private views being copied from one user to another. I've done this a stack of times. Unless something has changed in the most recent versions, the user objects are loaded when the user logs on.

Making a view public is another matter, but I find it easier to copy those to to my own admin login's folder, log out and back on, and publish them from there. Or, as Martin suggested, you could temporarily make the user an Admin. (That'll never, ever happen on my system, but that's an administrative choice rather than a technical one.)

Martin Ryan wrote:There's been a request on this for a couple of years (such as this one http://forums.olapforums.com/viewtopic.php?f=19&t=266 and I was assured at the time that it was on the radar...)

Only problem is that a feature like this can't be put into a promotional video of pretty multi-coloured web dashboards, and sports cars with red lit instrument panels rushing down darkened roadways. It's therefore not a priority. But I'm sure that we're always welcome to submit a business case for it...

ajain86 wrote:You could build a process that would call a script file which would copy the .vue files from one user to another. This would be a complex implementation.

Actually the implementation of doing that by itself isn't all that complex. Unfortunately the big potential "gotcha" is if the views also use private subsets. You need to have a way of reading the view file or definition to determine the names of those, then have the process copy the relevant subset files as well. There are ways of doing that too (both via the API and I can even think how to do it in TI), but yeah, that's where it can get complex and very ugly. If there aren't any private subsets involved, then obviously you can get away with just copying the .vue file. But for regular use, I wouldn't regard that as being a safe assumption.

The other issue is that there's no way of having the "target" user say that they don't want the view.
Target User: "Hey, what's going on, my views are all screwed up!"
Source user: "Oh, those are MY views of that name. I thought you'd like a copy of them so I sent them to you."
Target user: "You overwrote my views?? DO YOU HAVE ANY IDEA HOW LONG IT TOOK ME TO CREATE THOSE???"
{Coffee cup flies across the cubicle...}

Thanks for all valuable replies.
It is good to know that I do not need to unload the cube and it is enough to get user re-login.
It is also quite useful to know that user objects are re-loaded when user logs in.
Regards,

Alan Kirk wrote: Actually the implementation of doing that by itself isn't all that complex. Unfortunately the big potential "gotcha" is if the views also use private subsets. You need to have a way of reading the view file or definition to determine the names of those, then have the process copy the relevant subset files as well. There are ways of doing that too (both via the API and I can even think how to do it in TI), but yeah, that's where it can get complex and very ugly. If there aren't any private subsets involved, then obviously you can get away with just copying the .vue file. But for regular use, I wouldn't regard that as being a safe assumption.

The other issue is that there's no way of having the "target" user say that they don't want the view.
Target User: "Hey, what's going on, my views are all screwed up!"
Source user: "Oh, those are MY views of that name. I thought you'd like a copy of them so I sent them to you."
Target user: "You overwrote my views?? DO YOU HAVE ANY IDEA HOW LONG IT TOOK ME TO CREATE THOSE???"
{Coffee cup flies across the cubicle...}

Alan,

The implementation that I use does account for private subsets when copying over the view. It copies over the private subsets from the source to the target user. Also it appends the view name with the Source user so the Target user knows where the view came from and it does not overwrite any views.

On a side note... I love the dialog you wrote at the end.

Regards,

Ankur

ajain86 wrote: The implementation that I use does account for private subsets when copying over the view. It copies over the private subsets from the source to the target user. Also it appends the view name with the Source user so the Target user knows where the view came from and it does not overwrite any views.

Just wondering: do you mean that you just copy ALL of the private subsets of the 'source user'? Copy all of the private ones that belong to a dimension belonging to the cube?

Alan, you seem to imply that you could derive - only using TI - somehow exactly which private subsets - if any - to copy in such a case. How would you go about this if I may ask? (Or do you mean that you would expect it to be 'input' to your TI, i.e. the user has to specify the names of the subsets).

Jeroen Eynikel wrote:

ajain86 wrote: The implementation that I use does account for private subsets when copying over the view. It copies over the private subsets from the source to the target user. Also it appends the view name with the Source user so the Target user knows where the view came from and it does not overwrite any views.

Just wondering: do you mean that you just copy ALL of the private subsets of the 'source user'? Copy all of the private ones that belong to a dimension belonging to the cube?

That question occurred to me as well, but I decided to just let it slide; I assumed that was what was being done. The other issue is that copying the subsets would still raise the same risk of overwriting the target user's own subsets, since those, you can't rename without breaking the view.

Jeroen Eynikel wrote:Alan, you seem to imply that you could derive - only using TI - somehow exactly which private subsets - if any - to copy in such a case. How would you go about this if I may ask? (Or do you mean that you would expect it to be 'input' to your TI, i.e. the user has to specify the names of the subsets).

The .vue files are plain text files. In theory it would therefore be possible to use them as the data source and allow TI to "read" them to derive the subset names. A little bit of "fileexists" logic (coupled with WhoAmI code) could determine (by testing for the presence of a .sub file in the user's folder) whether the named subset was private or public. Haven't tried it my own self, but it seems quite feasible.