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.
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
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
When assigning a work item in TFS 2010 to a user i receive the following error
TF20015: The field 'Assigned To' contains the value 'User Name' that is not in the list of supported values.'
I tried to remove the user completly from TFS so that i can freshly add the user again, i removed the user from all the projects that i see but the user is still displayed in the 'Assigned To' list
I am having this issue with just one user in our production TFS project but the user do not have any issues in the our TFS test project. By this i think it is not an AD issue. How do i completly remove the user from TFS.
Can someone please help?
Solution: User has extra space in the AD account. Space was removed from the AD account but even after removing the user from all the groups user was still in the db. Had to remove the space in the db from the following tables and add the user back to the group
[dbo].[ADObjects]
dbo.tbl_security_identity_cache
dbo.Constants
This link is an overview but I will give you some SIMPLE STEPS below: https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel
1) In TFS use a query to find all work items with this user who no longer exists
2) Save the query (I saved to "My Queries")
3) Run the Query
4) Select Open in Microsoft Office -> Open Query in Excel
5) Excel Opens, Remove the User from the Column for each record, top to bottom blank out that column
6) Click Publish and it will put all of those Work Items back WITHOUT his/her name on them
Done
In order to make sure that obsolete versions of the product aren't selected for a work item's iteration, I would like to be able to cloak certain iteration nodes from view, when opening a new work item.
For example, if the current production version of my site is 3.5, and 3.6 and 4.0 are in development, I want to make sure that when a user creates a new work item, versions that are older than 3.5 (e.g. 3.4, 2.7) will not be selectable.
I can conceive of a way to do this creating a custom control, but I'd like to avoid those, as they'd require development of both desktop and web controls, and would have to be deployed to all users.
Any ideas, directions, or just an "it can't be done", would be appreciated.
Thanks,
Assaf.
I am not sure if you can hide it as a selection.
However you can set the security for "Edit work items in this node" to deny and they will not be able to save workitems with the area or iteration selected.
I'm 90% sure it can't be done.
I haven't tried this myself:
Along the line of access control, I believe if you deny "View this node" permission on a user then she will not be able to see this node at all. Be aware that she will probably not be able to see the work items that are under this node, but I guess you are fine with that.
Another thing to note is that this solution might not work with Administrators (because if all Administrators are denied view permission and cannot see the area path then it's lost forever).
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.