Changing owners of repository workspaces
as documented in the online help, the transfer of the ownership can be done by the current user or by the repository admin.
https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/t_scm_eclipse_change_ws_owner.html&scope=null
1.) Is is it correct that "repository admin" is the role JazzAdmins?
2.) If so, is there a plan to switch it to the project administrators?
We've tested it with 3.0.1.5 and the project admins don't have sufficient rights.
This is not useful in an enterprise environment, as we can't grant the JazzAdmins role to several persons in the project, and we as administrators won't be responsible for changing owners for workspaces in projects.
greetings georg.
2 answers
For example, "the workspaces of any member of that project area" would not be a good answer, since that would allow any project admin to change the owner of any workspace, by just adding that user to their project area.
Comments
Good point Geoff. That did not come into my mind.
Hello Geoffrey,
don't ask me, ask the system architect.
We had a RTC instance where several users had JazzAdmins rights.
After changing this system according to our security regulations they are complaining about not being able to work as before.
Feel free to reject the RFE.
The way it is implemented now is not useful for enterprise environments.
Georg,
"The way it is implemented now is not useful for enterprise environments."
This is a very broad statement and actually reflects specifically your environment. The problem is, that there are no standards and every enterprise comes up with their own standards. It is problematic to work around all the rules that people create, especially because these rules often look nice on paper, but render operations impossible complex.
Having said that, while it does not address having more fine grained repository permissions here a proposal.
It would be possible to create a tool that can be called by ordinary users and uses the API and a special Admin user and his password to do this kind of maintenance. It could be written with the plain Java Client Libraries. The admin user and password could be built in or stored somewhere so that the users can't get at it. You could require the tool to log in with the credentials of the user first, to make sure they have at least access to RTC. The tool would only expose commands you want users to be able to.
Another thing to mention. A user without JazzAdmin permissions can not even see a repository workspace that is owned by another user and set to private visibility.
If it is visible to the public or another broader scope, a user can find it if there is read access to the scope. In this case the user can duplicate the repository workspace. There is very few information the copy won't bring over, mainly work item relationships and comments for change sets that are not complete. The duplicate is then owned by that user and they can do with it whatever they please to.
So the question comes down to, why would you have to change the owner in the first place and is this really necessary?
I can only see the "user is on vacation" border case where you actually would want to change the owner of a work space. In all other cases that come into mind, either creating a duplicate or the normal RTC integration flows should be enough.
Can you come up with another use case that requires to change the owner?