No cmdlets to manage work item tags?

[smholvoet]

Could it be the case that are currently no cmdlets to manage work item tags?

I've noticed the Add/Get/Remove-VSTeamBuildTag cmdlets, which are build tags, not work item tags.

I feel like this could be a useful addition. Can I go ahead and launch a PR for this one? 🤔

[kilasuit]

@smholvoet if you are willing to put in a PR I am sure that it will be appreciated by the maintainers. Just be sure to read the Contributing file before you start down this path.

[SebastianSchuetze]

You don't need a new cmdlet. You can use the Add or Update work item cmdlet. The parameter additional fields allows you to fill any field (also custom) for a work item type.

Check the PR #190

[smholvoet]

@SebastianSchuetze Alright, I did not notice that. However, I still think there's a gap tho:

• ✅ Add tags: could indeed be done via Update-VSTeamWorkItem.
• 🟠Update tag: you can update a work item the same way you could update any other work item field, again through Update-VSTeamWorkItem. However, you currently can't update an existing tag which might be linked to let's say 200 work items (e.g. rename "old-tag" to "new-tag".
• ❌Get a single tag: list the details of a specific tag
• ❌Get all tags within a specific team project
• ❌Remove a tag; completely remove a tag which will also strip it from all work items it was linked to

So my suggestion would be 3 new cmdlets:

• Get-VSTeamWorkItemTag
• Update-VSTeamWorkItemTag
• Remove-VSTeamWorkItemTag

[SebastianSchuetze]

Could you suggest also the parameters you want to include so I can better understand how you want to implement it?

Otherwise go for it. Just asking you before you start scripting so you don't make something that we need to change later. 🙂

[SebastianSchuetze]

To add something. It would be good if those cmdlets support changing a tag for one workitem (providing ID) or changing the tag for a whole project (providing the project).

The get could support organization, project or only workitem level. Depends on what is possible and make sense for you or withe the API.

Also try to reuse existing cmdlets in yours if possible and where it suits.

Additionally keep the style of implementation the same as the existing cmdlets. Make it easier do review for us and also more konsistent with the current code base.