It's all about the answers!

Ask a question

Avoid removing or unlinking workitem from Changeset


vinitha dsouza (14719119) | asked Jan 10 '19, 8:48 a.m.
retagged Jan 25 '19, 10:11 a.m. by Ken Tessier (84117)
Dear Team,
Usecase: Do not Allow Removal of workitem linked to Changeset or viceversa.

Currently we are restricting the user not to deliver the Changeset without workitem.
But after Delivered to Stream, Users are able to remove the linking of Changeset from Workitem or even go to history and remove the link to workitem.

Do you have any idea how can i avoid this?

Thanks

Accepted answer


permanent link
Ralph Schoon (63.1k33645) | answered Jan 10 '19, 11:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

To add to Baraths answer, there is a specific permission that grants roles permission to save/modify change set links 

(Source Control>Save Change Set Links and Comments (server)) but this does not distinguish between adding or removing. A developer has to be able to add a change set link so they have the permission to delete it as well.


From my perspective it would also not make sense that a developer can only add a link. They need to be able to correct  stuff. You also want to consider that you can create a bureaucratic nightmare if you have too many rules. A developer only being able to add a link to a change set and having to get an admin to remove it in case it was accidental makes no sense.

Controlling of change set creation and removal can be controlled using operational behavior. In Source Control>Save Change Set Links and Comments (server) operation behavior there are 4 advisors that e.g. prevent from linking to closed work items etc. It is possible to create custom advisors if it is possible to find a useful rule. In this case you might consider prevent removal of work item links to change sets if the change set is complete, or some other rule. 

This is something that services could provide.

vinitha dsouza selected this answer as the correct answer

Comments
vinitha dsouza commented Jan 11 '19, 2:19 a.m.
ok thanks.
may be to avoid above case, it is better to have precondition on the above mentioned advisory for checking minimum one workitem link must exist for Changeset.

what is your thought on this?

Ralph Schoon commented Jan 11 '19, 6:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

That is a valid approach, it at least allows the user to provide a correct link and it is easy to check. I proposed a complete change set requires a link, because it will not change any more and is likely delivered. You have to find your requirements, but keep in mind that you want the tools still easy to use and not getting into the way for reasonable use cases like, for example, having the wrong work item linked. You want to allow the developer to achieve a fix without having to go to a manager or something.   

One other answer



permanent link
Bharath Rao (90034) | answered Jan 10 '19, 9:53 a.m.
edited Jan 10 '19, 10:11 a.m.
You could remove the permission "Modify work item links" for that particular role.

Refer:

Please let me know if you still need help!

Comments
Ralph Schoon commented Jan 10 '19, 10:45 a.m. | edited Jan 10 '19, 10:45 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I have looked there as well, but could not find change sets in the links available. Are you sure? In addition, as far as I know, the change set links are managed in the SCM component. 


Ralph Schoon commented Jan 10 '19, 10:47 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 Never mind, found it.


vinitha dsouza commented Jan 29 '19, 6:30 a.m.
Sorry above permission not helpful in this our case.
because, this is combined for add or remove. we we take this off then users can add a link as well.
another quesion: What is closed changeset? do you mean Complete Changeset?

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.