Jump to content

per User/Group XLinks/Cloaking?


Andy22

Recommended Posts

Hi,

 

i wonder if the following scenario is possible and "usable".

 

A main project folder that has common shared XLinks and per user/group XLinks.

 

Project Root

    XLink1-shared

    XLink2-Group("Artists")

    XLink2-Group("Programmers")

 

In our case this means that we have a Unity project and it needs certain plugins/libs that should reside in a "shared Plugin" repo that is always needed. Than each user/type depending on what plugins he needs might have extra/optional plugins he works with. Those are mainly artist/programmer, since many plugins have a per seat license and the artist don't need programmer plugins and vice versa.

 

So whats the best way to solve this problem? Ideally i would like to have the ability to setup the XLinks on a per user basis, means optional/extra plugin repos for artist/programmer/level designer and than just assign each user to a specific group. Than if this user updates his workspace only gets the shared/common XLinks and the optionals depending to what group he belongs. Additionally we could setup write repo rights for those optional repos, so one members could update those for all others in the group, essentially becoming the optional plugins repo admin.

 

 

I also wonder how things like per user Editor settings are handled? s it feasible to use plastic to also have a nice, clean way of storing per user settings in the SCM per project/global? So that users don't have to setup separate systems like dropbox? I suspect this means u need 1 repo per user, that stores all user specific settings and somehow XLINK those in your local workspace?

 

Thx Andy

Link to comment
Share on other sites

  • 2 weeks later...

Hi,

 

If you need to share different projects in Plastic, I recommend you to use Xlinks. Then, you can configure the user permissions or group permissions if you need to configure custom permissions per repository.

 

Just remember that the Xlinks are created at repository level (not workspace level).

 

For instance, in your scenario, you could allow, the permission of the artists on "Artists" repository and deny the permissions for the "Programmers" repository.

 

Regards,

Carlos

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...