How to share user (sub-) folders with other users?

[FrankPoppe]

Hi,

We have a bunch of EG users, and we encourage them to store their projects in the SAS Folders structure. For well defined projects we have folders for which some groups of users have write access (and some selected users may create new folders there). They also can register tables in those folders.

But sometimes users want to share things (experiments e.g.) they have done with other users. A logical way to accomplish that (we thought) would be if they would grant the read metadata right to selected people on items (or a subfolder) in their My Folder.

That appears possible (you also have to grant RM on My Folder itself, which is logical).

However, while it is possible to see those items then using DI Studio, through the User Folders item in the Folders tab, Enterprise Guide does not show that User Folders. Is this an option or capability that can be turned on? Or should we not use My Folder in this way?

Frank Poppe

PW Consulting, the Netherlands

[SASKiwi]

My guess is that My Folder is a special case of SAS metadata folders because they are created automatically when new users are added to SAS Management Console.

In EG the My Folder is identified by a different icon in SAS Folder View and hence access is restricted in EG to only your personal folder.

There would be no problem setting up a shared "collaboration" folder (eg \Shared) where EG projects and applications can be shared between users as long as the security is set up appropriately. 

[FrankPoppe]

Thanks for the reaction.

Maybe a separate collaboration folder is then the best option.

To get the same functionality we would have to create a separate folder for each user that wants to share work with others, giving create, delete and administer rights in the folder to that user, which is slightly more cumbersome than I had hoped for.

[jakarman]

The "My folder" is a logical redirect to "\User Folders\<user>" it is even called a short-cut like the approach at Windows.

As it is a common policy (every OS) not allowing users to see others people data/documents (profiles and other settings) it makes sense to have that protected.

Your question on "adhoc" collaboration is a classic one for a shared storage location and always being cursed for the uncontrolled and unmanaged effects of that.

It is possible to store and exchange all kind of data (indluding word/pdf) using the SAS metadata.

This adhoc request approach often lives in some limited projectgroups.or departments   What you can do is defining

/adhoc/dep/<collgrpa>   

/adhoc/prj/<collgrpb>   

allowing the users to work there restricted by group using an act and group with naming in the same structure. Giving each group a person that is responsible (user) you can access him and do cleanups.

When RBAC is in place that can be made part of it by the naming of organizational-groups.  Working in organizational groups goes often along with the sharing of storage (memo-s documents).

As the wheel has been invented already why try to invent it again?

[FrankPoppe]

I realize that we are not trying to do something entirely new, which is why I posted the question here.

In our initial approach it proved very simple to create the required metadata rights - but there seemed to be no way to access the folders using EG.

If it has to be a separate ad-hoc folder, it will of course be wise to try to use the existing group and role structure for the authorization. But I (in fact: the users) would prefer something where the person that places something in such a folder or sub folder remains the only that can change or delete those items.

I don't see how to accomplish that without creating an ad-hoc folder per user.

[Patrick]

Not sure if it would be possible to create a common dumping ground where you would have different owners per object - and only the owner would have full access to the object. But even if it would be possible I believe it wouldn't be a good idea. Who would get rid of all the clutter which would stack up in such a folder over time?

From what you describe it might be a good idea to have such a public folder per user. If you're having a lot of users then you could implement a script which sets up everything when adding a user to metadata (would need a bit of coding and testing so only worth it if there are enough users/changes).

[Patrick]

I agree with everything wrote. Just adding a warning: Don't take departmental folder structures too far as the next reorganization is already around the corner....

If you can: Try to create a "logical workgroup" folder structure as this will eventually change less often (if you're lucky) than departmental structures.

[jakarman]

Yes Patrick  you are right do not take departmental namings too strictly. They are often moving faster than anything else in a project. A moving target is a nice shooting game, bad for the results.

[FrankPoppe]

Regarding departmental naming: agreed!

As I said, our folder structure is by domain and project within domain.

The authorization is through a hierarchy of organizational groups. But the relation between identities and the lowest level of organization is extracted using a script through LDAP, and the naming of those low-level group is such that we can create (automatically with another script) the necessary higher levels and memberships (low-level group GROUP_ALL_AA_BB_CC is member of GROUP_ALL_AA_BB, which is member of GROUP_ALL_AA, which is member of GROUP_ALL).

The authorizations mostly are at higher levels, so only in a big reorganization we will have to do something about the authorizations on the project folders.

It should not be that difficult to add a script that makes certain that there is an ad-hoc folder for every identity that has an EG-role.

[jakarman]

Frank, that is correct. I stopped at the level of <collgrpa> and <collgrpb>.

There you have two choices.
a- The responsible user/person (not the sas admin) is allowed to create folders and set rights to them.

    He will need the SMC open with the menu-s doing that.

    Sometimes indicated as a restricted security officer (RSO) or business DBA admin role.

  I have seen Windows shares being open in the same way.

  Statement: The owner is responsible for setting the access rights. Windows has this structure and there is a takeownership command.

  Because is was used very intensive it caused issues with migrations backup/restore. (losing all those settings)  

  What happened? They closed this options for user. Wanting this kind of security requirements solved being regular.

b- The central administration solves all this.

     Less or more automated  described as a process.  I think there are batch-tools that will helpful for that.

     In that case with described processes the fixed layout is always done even when not needed.

     Better it is there when needed as having to invent something when being asked.