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
Related
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)
Is there a way to remove "Related Work Items" from a Code Review Request that was mistakenly added? (TFS2012, update2)
How about for another user?
Thanks!
No, it's impossible. Since the work item is related during the "pending changes" page. After the code review request created, there is no way to edit the related work item.
If you want to remove the wrong work item. So you may need to abandon this code request first. And in the "pending changes" page, right click the work item to remove work item. Create a code review request then.
After upgrading to TFS 2015 we are seeing all users in the collection being displayed as options for the Assigned To fields of a Work Item.
In 2013 we had set an ALLOWEDVALUES rule set to [project]\Contributors. It would restrict the list in the drop down to only the values in that group.
Now the drop down shows everyone and only complains if you try to select a user from the complete list that is NOT in the contributors groups.
How do we get the old behavior back?
In many organization, the work item type is shared across many teams. The old dropdown was long and was cluttered with people you would never assign a work item to. We heard a lot of requests to make assigning to people a much better experience.
We have changed the work item control to a MRU control so people you care about most show up immediately. And there is a "search more" option to find people which are not in the MRU yet.
We are aware that it is not possible anymore to restrict the list with the rules you define on the work item. It was an explicit design decision, and the rule is still enforced on save as you indicate.
Ewald Hofman - TFS Program Manager
You can follow below steps:
Creat a collection level group. Team Explorer-->Team Project Collection Settings-->Group Membership-->New-->Group name: MyTeam--> Double-click [your collection]\MyTem-->select Windows User or Group-->Add-->add users
Create a "Issue" work item type. Tool-->Process Editor-->Work Item Types-->Open WIT from server-->Copy an existing work item type and change the name as "issue".
In Field tab, double-click Assigned To-->Rules-->New-->ALLOWEDVALUES-->in ALLOWEDVALUES window, click New-->in List Item Edit window, enter [Project]\MyTeam-->OK, then save this work item type.
For test:
4. Create a new "issue" item, in Assigned To drop down list, you can only see the users you add in MyTeam.
We use Visual Studio Online.
We've been experiencing this issue over the past two days, when adding a new Product Backlog Item into the backlog view.
When we add an item from the quick add form in the backlog, TFS displays error TF400486. The item is saved and given an ID number, however, the spinner displays continuously. If further items are added from this screen, they will not save. A screen shot of the error is below.
The full error text is:
TF400486: Unable to complete the operation because you or another user has modified, removed, or re-parented items, or you are trying to reorder an item outside of its immediate parent.
Adding an item via the Work>Queries>New>Product Backlog Item does work correctly.
Any ideas what might be going wrong in the backlog view?
We had this same error and found a workaround. We removed the link to a parent Workitem and then could do Drag & Drop again. This was true even after we relinked the user story with their former parent elements again.
I hope this helps.
We never found the root of this error.
It sounds like a caching issue for that page. Try using private mode (InPrivate) or clearing the cache for that browser.
Make sure you don't have another iteration path with the same name. If so, it prevents items from being reordered.
In my case i added sufix (2022) on my the old iteration path T01-JAN-01
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.