TM1 Forum

Given that TM1 security is group based and most companies have divisions that look after certain sections of the company, I think it would be useful for non-administrative users to be able to share a view they think is useful with other members of their security group.

My suggestion would be giving the users the option when saving a view of making it private or making it public to other members of one or more security groups that they are a part of. I.e. they cannot create global views still, but they can share their views with other users who work in a similar space to them.

I'd then like admin users to be able to assign views to one or more groups, instead of just been private or globablly public.

Other alternatives or tweaks to my suggestion?

Martin

Can't you currently do something similar to this with Applications?

Kind of, but I see two problems with what you can do with applications. First and worst, it has to be the administrator that creates the public view and saves it in the Applications folder. Joe User can't do it. Second, the public view still clutters up the list of views under the cube in Server Explorer for those users who aren't interested in the view.

Martin

This is indeed a pain. When somebody creates a view the will more than likely want to publish it. In the current format the only possible way is by excel. This pushes users away from server explorer in to excel. This may (and does) make users think that TM1 is nothing more than a tool for dumping data in to excel,

Jim.

...and the knock on effect would be the ability to create views that a TI can use, but Joe User cannot see. That's a real pain in the posterior, especially when the TI function to create a view is broken in your version!

The only way round the TI thing I found was to set a naming standard for them and tell all users. I currently name all TI views "z - example". Starting every one with Z means that they always appear at the bottom of the view list,

Jim.

yep, i do something similar - "z - example" for temp views and "PRO - example" for anything that is needed regulary for TIs. Problem is tho its really easy to use the mouse wheel to scroll up and down a cube view as you would an excel file, but if the drop down was last clicked it'll scroll the view selector instead. Happened to me plenty of times but it wouldn't be so bad if i had "valid" views only

Very true. it is a real pain for us as some of our cubes are very big. We shift at least 2 years worth of data (via TI and due to hierarchy changes) each week. We use views for this and as you can imagine they are quit big,

Jim.

I also use the zView convention, but often double click to change the view when I mean to right click and export as ascii data to revise it.

If we resolve that issue with security then Administrators are still going to trip over themselves - I'm still going to double click and Steve's still going to scroll down in the cube viewer. So I think the resolution to that problem would be better served by a whole new object that cannot be opened by the Cube Viewer.

From Steve and Jim I'm getting the impression that the big TI views are a much bigger problem than having views that groups of users can share. Am I the only person who gets requests from users to be able to publish views to their colleagues?

Martin

Martin,

I do see the benefit of being able to share views. I don't think it is seen as urgent by most people as you can dump the view in to excel and email it to people which basically achieves the same thing. I do feel however this takes away from the cube viewer. I feel it would be more utilised if Cognos introduced what you are suggesting,

Jim.

My only concern with this one is that if you have say 10 users in a group, and a particular set of views is only relevant to 2 of them, the other 8 are going to have those views cluttering up theit views list. In that respect it may be a better idea to have the ability to publish the views to one or more individuals in a security group, rather than to the whole security group.

This also raises the question of whether the originator should be the only one who can update the view... or whether (as now) if a view created by User X is copied to User Y's folder, user Y can then modify the view as they wish. I probably lean more toward the former option, since USUALLY the whole point of "sharing" a view would be to ensure that everyone's seeing the same data.

However in conjunction with this, I'd like to see an easier way of COPYING views from one user to another, so that (in the instance above) user Y DOES have a personal copy of the view that they can modify as they like. This covers situations where someone may be leaving a job and wants to "hand off" all of their views, something that happens regularly with my own user base. At present we do this manually via the file system, but we have to watch out for any custom subsets that may form part of the view as well. There's no reason why that process couldn't be automated and TM1 could handle copying both views and subsets.

(Although it's a separate topic, I concur with the comments made in this thread about views used as TI data sources. This despite the fact that I never, EVER use pre-defined views as a data source; I always build them on the fly to make sure that they exist in an uncorrupted state, then destroy them at the end of a chore. The views lists are cluttered enough as it is...)

Alan, I think the point you have raised is an interesting one. If there is a function to copy views added then on the options list you have users, groups or everyone then it kind fits all.

yep sounds good to me too, we also have instances where a user has created a view and would like to share it with their team / security group. There is an array of options that, if planned out correctly, Cognos could improve no end

This is a bit old, but wanted to get back into it as it's coming up again here on a regular basis and I want to submit it formally to Cognos.

To distill all the above posts I think the consensus is that it would be very useful for a user to be able to save a view, then publish it to a selection of users. That selection could be individuals or all members of a group.

Technically I think what would occur is that the .vue file in the users sub directory would be copied to other users' sub directories also. The immediate availability of that view to other users may require something similar to CubeWise's hot promote, but I'm sure Cognos can make that happen.

The difficulty I see is when you have a user base of say >20. That means there is a long list of check boxes to choose. Or perhaps the subset editor for the }Clients dimension could be used, with users in the same security group(s) already selected.

Any advances on this? Otherwise I'll write something up and submit it to Dave Corbett. Be useful if some other people would be happy to submit it as well as I have zero standing in the Iboglix world because I'm a freelance contractor. I'll post the finished document up here for those willing to do so.

Martin

How about an alternative option:

When a view is published by a user to a group. It publishes it as a public view, with read permissions to only the desired group(s), and no permissions for other groups. This gets around the problem of having view contention in multiple users' directories; as well as the problem of maintenance.

Just my $0.02.

That doesn't solve the problem Alan mentions of wanting to share the view between 2 or 3 users, but not the entire group. I think this is valid, because most of the time user A wants to show user B something. Or (in my case) accountant is building a view for CFO's use. There's no need for everyone in the group to have it.

Martin

Perhaps it does not solve that specific issue, however, it certainly is better than allowing a user to copy over another users views and perhaps destroying a similarly named one inadvertently. It also introduces the perception that the copy is linked to the original view, such that if someone makes changes to it, they could be out of sync and cause confusion.

Ok, so how about a few more ideas:

1) What if the owner was able to grant security priviledges to other users? Therefore, when the viewer then expands the list of cube views, they would see the other users name as a folder. When they expand it, then it would show only those that the user had permissions to view.

2) Another option would be the ability to send / email a view to another user, that they could then "save as". This does not solve the sync problem directly, but what it does enforce is the notion that you are receiving a file from someone and you can do with it what you want; rather than the perception that you are looking at another users' view.

Personally, I like #1, but I don't know how well that fits into the security model internally.

I've written an open letter here. If anyone would like to edit, please do so. Then I, for one, will copy it into Word, pretty it up and email it off to the Cognos team.

NB, you'll have to register with Olapedia in order to edit it. Email confirmation is required to get around the spam issue we've been having.

I've added a section to the TM1 section of Olapedia that has open letters to Cognos requesting enhancements. If anyone wants to draft up other requests, please feel free, then people who agree can email them off too.

Cheers,
Martin

blackhawk wrote:Perhaps it does not solve that specific issue, however, it certainly is better than allowing a user to copy over another users views and perhaps destroying a similarly named one inadvertently. It also introduces the perception that the copy is linked to the original view, such that if someone makes changes to it, they could be out of sync and cause confusion.

Ok, so how about a few more ideas:

1) What if the owner was able to grant security priviledges to other users? Therefore, when the viewer then expands the list of cube views, they would see the other users name as a folder. When they expand it, then it would show only those that the user had permissions to view.

2) Another option would be the ability to send / email a view to another user, that they could then "save as". This does not solve the sync problem directly, but what it does enforce is the notion that you are receiving a file from someone and you can do with it what you want; rather than the perception that you are looking at another users' view.

Personally, I like #1, but I don't know how well that fits into the security model internally.

It'd require a complete revamp of it, I would think. Not that this is necessarily a bad thing; but it's something to bear in mind in terms of how much work Iboglix will need to put in to implement it and, consequently, how likely they are to do it.

At present there's no actual security (in the sense that it exists for, say, dimension elements) for views. A .vue file will appear in one of two places; either in Datafolder\CubeName}vues, or Datafolder\UserName\CubeName}vues. If it's in the former then it's public, if it's in the latter then it's private to UserName. This is pretty easy to handle programatically; all of the public views are loaded when the server starts, all of the private views are loaded when the user logs in. (As evidenced by the fact that you can copy a .vue file to a user's personal folder while the server is still running, and all they need to do is log out and back in to see it. Refreshing doesn't work, but logging out and in does which implies that it's the login process which triggers the reading of the view specification into memory.)

If option 1 were to be adopted I think that any shared views would need to be loaded into memory on startup in the same way as Public views are, simply because the server would have no way of knowing which users who have access to them may log in during the session.

In addition, basing access for a "shared" object on users rather than groups would be a whole new model for TM1 security. As I said, at present objects which are "user-specific" are stored in user-specific folders and only loaded for that user when they log in. Accesss to "globally loaded" objects, on the other hand, is handled by user groups.

I don't think that the Save As option will necessarily fly, though, because:
(a) That would necessarily involve giving the users some write permissions to the server data folder (which would be more than a little risky) and
(b) It would be necessary to save not just the .vue file but also any related .sub files.

I do agree, though, that if the "file copy" methodology were to be adopted there would need to be safeguards on a person overwriting the target user's own views and subsets.

I think we are in danger of over complicating this and the more complicated it is the less chance we have getting it implemented. The basic request is quite simple.

A user should be able to pass a copy of one of their private views to another user. The other user should be able to see it without re-logging but an f5 refresh is acceptable and the view would appear as a private view of that user.

This would solve (IMO) 99% of the problem we have of comms between clients, which is often a telcon "Look at this / What does this mean?". The rest of the stuff is just twiddles that aren't really that important and nice to haves? Lokcing views and embedding this in the security structures just isn't important as getting the basic functionality working.

Just want to make sure that there is clairty about what the request if for.

Cheers,