Is there a way to query product backlog items (and their histories) to find what the parent of an unparented task was before the link was deleted?
For instance here I have two tasks that are showing up as unparented.
They used to be parented to a user story but the link has been broken. Rather than having to trawl all my user stories and look through the history, I would like to be able to run a query (for instance on item 253152) and it to tell me what the parent used to be.
Update 07 Apr 2022:
Miao Tian's answer is of course absolutely correct.
In our case the tasks appear to have never been parented. They where created by a third party tool which appears to have failed to link them correctly. I'll post more information if it is helpful when we get to the cause.
If you just need to find the parent of this work item in the past, you don't need to use query. You can directly open item 253152 to view its history.
example:
start
delete the link
check the history of the task and find the parent
Related
I am currently using devops (cloud) services. I have created a custom Work Item Type (WIT) within an inherited process from Agile. I would like to configure it to behave like exactly like Agile's User Story WIT. By this I mean:
The WIT should be addable in the taskboard view of the Sprints (see first pic, WorkItemTaskBoard).
One should be able to add tasks to the item just like User Story's.
The WIT should rank below features in the WIT hierarchy. This way when it is added as a child of a feature it will be visible in the Backlogs view (see second pic, BacklogChildMissing)
According to my reading I need to export my inherited process as an XML, edit said XML then import the modified XML. I have two issues with this.
A. I have not found any reliable documentation how to perform the above.
B. Although I am using cloud based Devops (dev.azure.com) and am the organization owner I do not appear to have rights to import a process (see third pic, ImportProcessMissing)
Can anyone confirm that I need to perform the export, edit, import the XML as specified above in order to achieve 1, 2 and 3? If so, I would need help in figuring out how to import the process.
WorkItemTaskBoard
BacklogChildMissing - The WIT is not displayed despite being a child of Test Feature.
ImportProcessMissing - Import button is missing.
You can follow the steps like as below image shows to configure the customer WIT in the inherited Agile process.
Create the custom WIT.
Set the custom WIT as the Stories backlog level.
After above settings, in the project which is using the inherited Agile process, you can manage the custom WIT like as User Story.
See below example:
I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.
I have a User Story against which there is an impediment faced in current sprint. Due to this impediment, we are not able to complete the US in this sprint. However we cannot also close it or mark it resolved. Since its open without any action, its also interfering with the burndown charts.
Can I get an advice on how we can handle impediments in Azure DevOps and thereby set that work has been halted/suspended on a particular user story? I was reading the related article here: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/manage-issues-impediments?view=azure-devops.
Thanks and Regards,
Satheesh Vijayan
As stated in the documentation:
You use issues or impediments to track items that may block work from
getting done. In general, you link these items to user stories or
other work items using a Related link type.
So as a workaround ,you can try customizing impediments tracking ,through this you can customize the item state,add a special state to impediment item . For details, see Customize an inheritance process.
Organization Settings -> Process -> Inheritance process -> Impediment ->State -> New state
Note: only inheritance process can be customized.
We're currently using Azure DevOps to manage work items (user stories, task , etc.). I'd like enable an event/trigger when I close the user story, the child task-status are also closed. Is this possible?
I saw within
User Story State Change to Update Work Items
Generally, we would like convert the parent work item state based on the linked child work item state, not the other way around.
Converting the child work item state based on the linked parent work item state may cause some unsafe issue. For example, if we have one child work item that is not completed, then we accidentally closed the parent work item. In this case, the incomplete child work item will also be closed incorrectly.
To resolve auto change parent states, there is a free solution on the marketplace available: TFS Aggregator, For VSTS, you need to use Web Hook to complete it. Please refer to this : https://github.com/tfsaggregator/tfsaggregator-webhooks.
Besides, if auto change the linked child work item states is your final requirement, You can use the Rest API to invoke state changes. You could check the post and the post for some more details.
Hope this helps.
When we are doing the customization of a work item type in VSTS. Do we also have the ability to track the history of the customization itself?
For example, we are trying to find out when the start date field was added to our customized Bug work item type.
A field was not there in a previous Increment but we noticed it recently. Just want to find out if there is a date captured somewhere that tells us when it was added or who may have added it?
Unfortunately we cannot get the information from VSTS for now. No date or history included from the retrieved process information via REST API.
However there's already a user voice submitted here to suggest the feature to add Activity Log to VSTS to track user accesses, you can go and vote it up or submit a new one to suggest the feature again to achieve that is future release.
For now as a workaround we suggest that you can ask the team members to add corresponding comments in description area after completing the customization for the process... Thus you can track the history of the customization...