-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to Update-VSTeamWorkItem to add relations with other work items #518
Comments
dup of (or related to) #228 |
@mnieto what do you think is |
@SebastianSchuetze On the other hand, implementing in separated cmdlets simplify the logic. In fact the az devops CLI implement the relations management in a separated command set. In both cases, my idea is to implement an internal function to retrieve the different relationship types and then use it to both create a dynamic parameter (RelationType) and to expose a new cmdlet Get-VSTeamWorkItemRelationTypes Then, I can implement a New-VSTeamWorkItemRelation cmdlet to generate a in-memory definition of the relation. In this way it's easier to validate the parameters and build the corresponding JsonPatchDocument. Also, with this only one cmdlet I expect to cover the use cases to add, remove or replace relations in the WorkItem. For eample: $relations = @()
$relations += New-VSTeamWorkItemRelation -RelationType Parent -Id 1502 -RelatedWorkItemId 903 -Operation Add
Update-VSTeamWorkItem -Id 1502 -Relations $relations But if you prefer implement the relationship management in a separate set of cmdlets (like in #228 proposal) it is fine also for me. Please send me your advice on this |
@mnieto Internal function is a clever idea, and I would go with the consistent approach done in Get-VSTeamWorkItem. Meaning We can update relations with Update-VSTeamWorkItem. But still, I would say that we expose cmdlets for doing relations stuff also with the same internal function. Would you give it a try? Did I express myself clear enough? |
It's clear.
All the above cmdlets will work internally with a JsonPatchDocument or compatible object. Also, below cmdlets will return this object/collection of objects respectively. Using this aproach, the -Relations paramter in the Update-VSTeamWorkItem can be built with the help of New-VSTeamWorkItemRelation or directly as the example at the very beginning of this thread.
|
Yes start. Just not sure if I understood. The minor changes would they mean that older scripts would break? |
No, what I mean is that during implementation perhaps I need to change some
parameter or function behaviour, but only for the planned cmdlets described
above
El mié, 24 may 2023, 21:10, Sebastian Schütze ***@***.***>
escribió:
… Yes start. Just not sure if I understood. The minor changes would they
mean that older scripts would break?
—
Reply to this email directly, view it on GitHub
<#518 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4X4XR3DTVVFKPEHVOCBI3XHZML3ANCNFSM6AAAAAAXMSBSPI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Proposal
Add a similar parameter as existing AdditionalFields, for example -Relations. This parameter can be a hashtable like this:
Solved Problem
This will allow to simplify the process to udpate work items with related ones
Additional info / code snippets?
There is a basic example of this in the
Add-VSTeamWorkItem
cmdlet using the -ParentId parameter. But this feature will allow to define additional relationships for a work itemThe text was updated successfully, but these errors were encountered: