During the time some work items are becoming invalid. The AssignedTo field (which is mandatory) has a value of a deleted account (people are leaving the organization).
What's the impact of these invalid work items on TFS performance/health?
Most of them are in Closed state so it's small chance that someone will open them again.
Should I maintain all work items in valid state?
For AssignedTo field ,you can remove the deleted and unused account by some settings.You need to add ALLOWEDVALUES rules with the project group which you want to be displayed in AssignedTo field. Please refer my answer in TFS-2015 limiting user list for more info.
For invail work items, it doesn't has any serious influence. There are general three treatments.
Just ignore it
Change the AssignedTo to others
If this work item will not be used in the future, you can delete it.
In the near future, easy way of deleting and recycleing a work item is coming on.
Visual Studio Team (Product Team, Microsoft) responded · Aug 29,
2015
We’ve started work on this one. We’re planning to add a real delete
into the UI… complete with a recycle bin. High level plan is to
deliver this around November of 2015.
Source: UserVoice
Related
I want to add in TFS query where parameter "Assigned to" will be equal to team member selected from dropdown list This oportunity exists in Work/Query. There will be great if I can put such query on overview.
I cannot find this option, is it possible? I'm using TFS 2015.
Derrick Fu MSFT #Brett – sorry for the frustration. With TFS2015, we
shipped a new user picking experience designed around an MRU list and
search experience. The “random” list of users you are seeing is
actually the most recent users you have assigned work items to. For
scoped person fields, we realize this is a bit of a takeback since you
no longer get a scoped list of users.
If you want, you can re-enable the old picking experience (without
MRU, search, and avatars) by running the following command on your TFS
instance: exec prc_SetRegistryValue 1,
‘#\Service\WorkItemTracking\Settings\UseTextControlForIdentityFields\’, true
This will change all person fields across the collection back to the
old behavior.
Source Link: VS2015 Update 2 and TFS 2015 Update 2 have shipped
There also has been a uservocie- Limit items in Assigned To Drop down to ALLOWEDVALUES in Web interface you can vote up it to get more attention.
Sorry the poor English.
I'm using Visual Studio Team Services for a first time, and I follow the guided tour where I created three work items as example. Basic conceptions learned, I then deleted these first example work items and started to Create my own work items. Their numbering was sequential to the three first ones.
I managed to delete my Project to start a new one. I was think a new Project will start its work items from number 1 onwards, but the numbering from the deleted one is being used. I tried creating the repository with another Project name but no success.
I wasn't able to find how this is occurring, and it's very annoying to me. Someone has any idea about what's going on and how to correct this behavior (unless this is a feature)? Thanks in advance.
In TFS you have a Collection Database, that has a WorkItem table, all Work Item Id's are sequential in that table. A Collection contain one or more Team Projects. To reset the numbers you would have to create a new Collection.
In VSTS Collections are not a concept that you can manage, you have an account instead, you would probably have to delete and re-create your account - I don't think there is any way to create a new Collection in your account - I may be wrong, I'm only a personal user of VSTS.
I wouldn't worry too much about what ID's each work item has. I don't think it matters that much, you will soon lose control of them. Every WI you create has a new incremental ID, you you get Bug #1, Test Case #2, PBI #3, and so on. If you have >1 Team Project you will also end up with that taking ID's from you.
We recently started using Team Foundation Server 2012 and are using the code-review feature to have other developers review code changes. It seems to work great; however, as a project lead I would like to be able to see that a given changeset has been reviewed by someone else.
For example, say Developer Bob makes changes and requests a review on those changes. This generates a shelveset for the changes and creates a code-review work item for the requested review. Developer Alice reviews the changes, makes some comments, and finishes the review. Bob incorporates Alice's suggestions and checks in the changeset.
As a project lead, I search for changesets and see that Bob checked in changeset 123. If I look at this changeset, there is an associated work item for the task Bob was working on, but no indication that the changeset was reviewed by anyone else.
If I look at code-review work items, I can find the things that have been reviewed and see the comments. This is cumbersome as I have to sift through work items and find the one that happens to be related.
How can I tell from a given changeset that it was reviewed, as well as see the review comments?
Changesets can be linked to any kind of Work Item, including Code Reviews. When you request a review on a set of pending changes, they are automatically associated to the new review Work Item. When you double click on the changeset you should be able to see under Related Work Items something like this:
In this case there were 2 reviews for this changeset, the second one was automatically there when it was requested. The first one had to be manually linked, just like the Task.
If you double click on the review item, you can see all the comments.
Tip: If you want to do a review post-checkin: go to the History view --> double click on the changeset --> Actions --> Request Review.
Tip2: It is a bit annoying that you have to manually check that each changeset has a review. If lack of review is really a problem for your team, I would suggest setting up a check-in policy.
You can make queries searching for code review work items and you will find associated changesets on the field Associated Context (Changeset id or Shelveset Name)
Inside the Code Review, you can check the changeset via the link at the top of the work item view.
Of course, there is another option that is querying directly to TFS Database (Warehouse) but it's tricky and requires access to that database and knowledge on the schema.
from work item history u can check out all the change sets ....changeset was reviewed by anyone else this functionality TFS does Not provide!
may be i have lost Something but i don't see any answer regarding to change set that is was reviewed.
but you can check the change through (history , and sort the source control by date ).
good luck!
Maybe my google-fu is failing me, but I cannot seem to find any information on the following:
My Windows user account was recently moved, accidentally, to another domain in my company's Active Directory. While in the other domain, I was unable to access my data stored in TFS 2008 (e.g. shelvesets, pending changes, workspaces, etc). I assume this was because it was associated with my ORIGINALDOMAIN\userId account, rather than NEWDOMAIN\userID account.
My account has now been moved back to ORIGINALDOMAIN, however I still cannot see any of my data in TFS. In fact, it appears that all of my data (all my shelvesets!) have been deleted. It is almost as if TFS saw that my userId had disappeared from ORIGINALDOMAIN and assumed that I had been "deleted" and thus deleted all my data.
Has anybody else encountered this? Is there hope for my data or am I royally stuffed?
Thanks in advance,
Steve
Update: I have now managed to track down some of my old shelvesets by doing a search for "*". Oddly, the shelvesets are now associated with NEWDOMAIN\userId. If I do an explicit search for shelvesets belonging to NEWDOMAIN\userId (or ORIGINALDOMAIN\userId) nothing is found. Still no trace of my pending changes or workspaces though...
So, I think I have (partially) got to the bottom of the problem. It appears that my data has been assigned to a user id of the form DOMAIN\userid:number, instead of simply DOMAIN/userid as might be expected.
This means that I can now find my shelvesets by searching for the fully qualified id. I still don't see any solution for resurrecting my previous pending changes or workspaces, however at least I can now retrieve the shelvesets back into my correct id.
Panic over for now.
Does anyone know if it is possible to prevent a work item from being assigned to a specific user account in TFS?
After migrating a TFS from one domain to another, some of my team members have two user accounts, the original one from the old domain, and a new one from the new domain. I'd like to stop work items from being assigned to the old account.
Most process templates restrict username fields with the rule. (If yours doesn't, you should do so.) Then all you need to do is remove the invalid accounts from TFS Valid Users group.
Unfortunately, you can't do this directly -- TFS manages this group automatically based on ACLs found throughout the rest of the system. You have to hunt them down. See these threads for more details:
http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/6e5af2ab-1cbc-4d12-9078-454147926316
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/1ce8b5b0-9924-45ed-919b-49a6a61bb7c7
Once you find all instances where the old domain is being referenced, the general strategy for cleaning up orphans is to add a new ACL, wait for TFS to sync (or iisreset), then remove everything.
However, this may not be possible if you've taken the old domain offline, or there's no trust relationship between the two domains, etc etc. At some point it becomes easier to edit TfsIntegration manually. I usually don't recommend mucking in the TFS databases since it's unsupported and subject to change with every patch. For optimum safety, I'd still strongly suggest using stored procedures rather than trying to interpret the schema relationships (and make sure you hold the necessary locks, etc). prc_security_delete_identity is your best entry point: all you need to know is the old account's SID.