Feature Request: Public/Private Roles

Dec 6, 2010 at 7:38 PM

Thanks for this great application.  It has made deployments go much easier in our organization.

One thing I'd like to see as an improvement is the idea of public and private roles.  We have 20 or so desktop staff and I have let them create any roles they want to as deploymernt templates to use for the departments they support.  The problem is that everyone sees everyone elses roles and it gets unwieldy.  I'd like to submit the idea that you only see the roles you create + public roles.  Administrators would be able to view all roles.  Administrators could take any existing role that has been created and mark it public thus locking it from edits and making it viewable to all users.

Users would only have rights to edit the private roles they created.

Maybe this is too hard to implement...  I am thinking about the webservice.  If I want a list of roles, how would it filter based on a user name - you authenticate to MDT Front End, but not necessarily the webservice so how would the webservice show you your own roles + public ones?  How would the web service know it is you?  Probably, it could not.  Also, what about role name colisions?  You go to create a role and that name could be already taken, but you wouldn't know because you only see your own roles + public ones.  This idea might be really hard to implement successfully...

It might be that the best that can be done is to be able to lock certain roles so they cannot be edited by non admins.

Feb 4, 2011 at 6:48 AM

well, interesting idea but as you mentioned already, some parts would have to be worked out first ;-)

Currently you can already specify what Users can edit what roles. If you have an AccessRole configured that allows to edit Roles, you can assign this to Users for either all or just specific instances. This way you can have Admins being able to edit all Roles and users editing only their own roles. It wouldn't prohibit anyone from seing the other roles and would (currently) also have no reference to the web service. But it should cover already part of your request. It's also often used for larger, more wide-spreaded environments, where you have several locations with their own IT. So you can have central IT with edit permission on all locations and local IT with edit permission only on their sites.