I use VSTS and tfs aggregator to update parent fields when I have some changes in work items, and every things work fine. Now I want to update parent field when I delete the work Item. and I get the error:
Exception encountered processing notification: TF26198:
The work item does not exist, or you do not have permission to access it.
Stack Trace:
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.LoadWorkItemFromRowSetInternal(Int32 rev, Nullable`1 asof, IWorkItemRowSets witem)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem..ctor(WorkItemStore store, Int32 id)
at Aggregator.Core.Facade.WorkItemRepository.GetWorkItem(Int32 workItemId)
at Aggregator.Core.EventProcessor.ProcessEvent(IRequestContext requestContext, INotification notification)
at Aggregator.WebHooks.Controllers.WorkItemController.Post(JObject payload)
It makes sense when I delete the workItem, there is no work item I could access via it to parent, But is there any way to get the deleted workItem's parent? any idea?
There is no simple answer to this.
We added support for the deleted event at some point, but Aggregator receives the event, after TFS has marked the work item as deleted. The API we use filters out those objects IIRC. The only useful piece of information you have is the ID of the deleted work item. Using PreviousRevision you might be able going back in time, but I haven't tried.
Source code is available and PR are always welcomed.
Update:
You can't do this.
The error is very clear:
The work item does not exist, or you do not have permission to access
it.
When you delete the work item through command, all information is also deleted. This permanently remove work items from the data store. A permanent delete means all information in the WIT data store is deleted and cannot be restored nor reactivated. You definitely could not query and update the deleted Work Item's parent.
Even if the work item exist "somewhere", then you don't have permission to open the work item, and also you can't query information about it. It's a bit of chicken/egg. Take a look at this similar question: TFS API: How to check if a work item has been deleted or is non existent on the TFS Server? (not if it is accessible)
Related
I made some changes and then requested Code Review in TFS, then realized I had made the changes to the wrong branch. So I tried to delete the work item to show that I no longer needed code review (at least in this branch). However, when I tried to do that, I got the beautiful red error:
Failed to delete work item: 1061. Error Details: VS402838: The work item 1061 cannot be deleted. Code Review Request work items cannot be deleted.
For now, I'll just have everybody complete the code review where it sits, and then I'll make the exact same changes in the correct branch. But I'm wondering what you are supposed to do in this case if they insist you can't delete Code Review Request work items.
This can be accomplished by creating a query that includes the desired work item, then editing it from within the query.
Create a new query, then specify criteria such as Created By (yourself) that will find the work item. ID doesn't work so well if the work item was already assigned out, as each reviewer has their own work item.
Right-Click the work item you want to edit.
Select edit from the context menu.
Steps 1-3:
In the window that comes up, enter "State" for Field and "Closed" for Value:
Enter some notes about the manual change and then close the dialog with the "OK" button, and then don't forget to save your changes with this button:
I think The Right Thing to do in TFS-land is to Abandon the Code Review, since you can't delete it from TFS.
The previous answers have two means of doing that. Here's a third, from within Visual Studio, since that seemed like a convenient alternative.
Open My Work in the Team Explorer window.
Find the Code Reviews section of My Work.
Right-click the Code Review you want to Abandon.
Select Open.
In the Code Review UI, select Close Review for the reason Abandon
Profit.
You can cancel a code review required by using excel
Please try this workaround: create a work query to get all that user’s Code Review Request work items which in Requested state, save this work item query and open this query in Excel, then edit them work items in Excel to change the state to Closed, then click Publish button to publish the updates to TFS Server.
See this URL https://social.msdn.microsoft.com/Forums/vstudio/en-US/83d96317-cdd7-436c-8415-fda54d1ce752/cancel-a-code-review-request?forum=tfsworkitemtracking
Trying to use OpsHub (free version) to migrate from on-prem TFS to VSTS. It is failing on a work item with the following error:
com.opshub.exceptions.eai.EAITFSPollerException: OpsHub-012310: Error
occurred in getting link/attachment information for WorkItem 46906
Revision 1. Caused By OH-TFS-Connector-0051: Operation failed
getLinkInformation. Server Error : TF26198: The work item does not
exist, or you do not have permission to access it.
I am able to access the work item. I did see the work item had 3 associated work items and I verified I could open all of those as well.
Any suggestions? I did get this with a few other work items and I purged them. I would like to know the cause as I anticipate running into this issue again and the process of manually removing the work items is costly as I do not have a list of all the problem work items. I have to resume the migration and wait for it to error.
Update: I have been able to identify the culprit. This work item is linked to another work item in a different project. Surprisingly I can't see that item even though I have collection admin. I'll keep working on it. I know the linked work item exists.
As Justin confirmed himself, the issue was Access Permission. The user through which the migration was running, could access the WIT in question and it's links. But could not access the linked WIT (which was from another project). Providing the permission to the migration user, by making him the 'Project Collection Administrator' solved the issue.
I receive the following error:
OH-TFS-Connector-0051: Operation failed getCollectionMetaData. Server Error : TF201063: Adding a Parent link to work item 1737 would result in a circular relationship. To create this link, evaluate the existing links, and remove one of the other links in the cycle.
I have completely flattened out the Work Items in the source project. When retrying the migration the timestamp is modified on the pending errors however the issues are not resolved. These Work Items now have no parents or children in the source project. So I'm wondering if the retry list is no longer valid but there doesn't appear to be a away to have it update?
I can run the whole migration again, however it takes 5-7 hours to just do the work items so it would be great if there is a quick fix.
Was able to solve this problem by doing the following;
Removing all links in the source for the work items with issues (recording this so it can be put back afterwards)
Ran migration again
Navigate to the task in question in the target. Notice that a new parent and child links were present (even though there should be none according to the source).
Opened the parent link and removed the child link then saved.
Then removed the child link in the parent.
Marked all items for Retry and restarted the migration.
Last task, is now to put the links back in the target as they were originally in the source.
I am looking to create an "undo" mechanism for a TFS work item using the TFS API - this will undo committed changes. Basically, after saving new data (also using the API) to the work item, I would like the option to revert the WorkItem back to the previous version.
Pseudo code something like this...
1)Get current Work Item for Id:xxxxxx
2)Get "revision id" of this latest
work item and store in "PreviousRevId"
3)Modify field values
4)Save
5)For
whatever reason we don't want these changes any more (domain logic as
to reasons are excluded for brevity)
6)Revert to old revision
("PreviousRevId") and make it the current (latest) revision
Have a look at the Work Item History Visualizer i created. By taking the work item Id, you can pull out the history of all work item fields.
http://geekswithblogs.net/TarunArora/archive/2011/08/21/tfs-sdk-work-item-history-visualizer-using-tfs-api.aspx
But this will only help you get the information, rest you'll have to build your own control to build the revert functionality.
EDIT: Also worth checking this visual studio extension **
http://visualstudiogallery.msdn.microsoft.com/d127b275-b7b6-4504-b01e-58b4a010ff53
This lets you see the work item as it was on the historic date. Giving you the baseline affect you are after. HTH
I don't think this could be achieved by SDK, you can do this against the DB directly but this is of course not recommended at all, anyway the main 2 tables to hold work items are WorkItemsWere and WorkItemsLates see the following:
There is no automatic way to revert, but it's an easy foreach loop to iterate through the fields to update them to the previous value. You also have to worry about links and attachments.
TFS stores information about who created or who activated a work item and for some reason checks its validity whenever the work item is modified.
When a user is deleted from active directory or renamed in active directory, all work items even slightly has connection with the user can not be modified. Usually the error message is something like ...
TF20015: The field 'Activated By' contains the value 'blah blah blah' that is not in the list of supported values.
I've found a blogpost which recommends tweaking the TFS database, which is something not supported nor recommended by Microsoft.
What can be done to resolve this?
Thanks...
e-mre
Caveat: I'm not sure that this will work, and right now I'm not in a position to test it. However, I've had success with this approach on some other fields.
If you use the TFS Power Tools to edit the work item type definition, you should be able to change the Activated By field's rules and add an ALLOWEXISTINGVALUE rule to it. This might allow you to save those records when the AD name changes.
We've used this with some success with the Assigned To field.
I've seen this behaviour. It occurs if someone who activated a work item is removed from Active Directory (leaves the company) or if they change their name (gets married).
It's simple to fix, you just need to change the work item status from Active to Pending then back to Active this will change the "Activated By" field to the person chaging the status and the problem will be resolved.
Are you using TFS 2008? I seem to remember that this issue is fixed in 2010 (but I might have dreamt that)
If you have a lot of work items this blog might have a solution that helps automate the fix.