These users never had MTM installed locally but seems to have different default for test case shared steps query.
I'm not sure where to find these queries saved. or how to clear if it's cache related.
I know if there is MTM installation on user local machine, it will save user config settings mtm.AddSharedStepsGrid somewhere in systemDrive:\Users\{UserName}\AppData\Local\Microsoft\TeamTest\v*" but this is also occurring on user machines without MTM installation.
It has different default per user, cause the user have used/changed the query before.
TFS web portal will auto cached the last query option which user have selected.
You could test this in your side, just change some options, close the “insert shared steps” query, then open it again, it will changed.
Since there is not any button to save the "insert shared steps" query, you could only Run it. I think this is by designed as a temporary storage per user instead of the "save" option.
We now only have the first row i.e. Work Item Type in group Shared Steps. That wouldn't be different per user.
Related
We are running TFS 2012. Our organization is currently creating new accounts for everyone as part of a migration.
What I know is that everyone will have two accounts listed in AD for a while:
OldDomain\DoeJ
NewDomain\DoeJ
This brings me to believe that SID will be different, among other things.
My question is, how would this affect our TFS environment? Will we lose any history associated with particular users? Will I have to go through each work item and reassign it to the new Windows account? Is there any way I can preserve this data?
Thanks
You could use Identities Command which lists or changes the security identifier (SID) of users and groups in your deployment of TFS. You might need to change or update the SID for users and groups in one of the following scenarios:
changing the domain of your deployment
changing from a workgroup to a domain or from a domain to a workgroup
migrating accounts across domains in Active Directory
Even though it's a powerful tool, but it has certain limitations. To help ensure a successful move, make sure that you understand the following requirements:
Once a user account is present in TFS, it cannot be removed or have another account mapped to it. For example, if you are moving
DomainA/UserA to DomainB/UserB, the Identities command would only
work to migrate the user if DomainB/UserB is not already present in
TFS.
Because the members of the local Administrators group are automatically added to TFS, make sure to remove any accounts that you
want migrated from that group before you change the domain or
environment.
Suggest you read up about this tutorial as part of planning your move. You could also take a look at this blog : Migrating TFS Server or Collection to another domain. Be careful do not add the user such as NewDomain\DoeJ to TFS first, after upgrade SID, the history will keep without any problem.
Moreover, TFS use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). You can force the job to run using any of these techniques.
We're using TFS 2013. The problem we're facing is this:
Several Active Directory users are listed in TFS under the Control panel/Security/Users, but not all.
Where can I control which AD users will also be able to access TFS?
The displayed names are only the names that have been assigned to something and synched into the TFS db's by the AD sync service. If you enter in the full AD name of a valid user in any of the security assignments it will end up showing in the user select list after the next sync run (every hour if I remember correctly).
I.e. you can assign users that are not displayed in the list.
Anyone know how to remove users in PlasticSCM when the server is configured to use Active Directory security?
The cm au/du commands are meant to activate or deactivate users.
But users are not 'added' to Plastic as such.
When a user does an operation in Plastic, it will be automatically added provided you have enough licences and the user has permissions to access the system (you've set the correct ACLs).
Suppose you just have a 20 users license:
You simply install the license (copy the plasticd.lic file)
Then the first user access the system, it will be 'activated'
Second user accesss, second 'activation', it happens automatically
Then suppose you already have 20 developers using Plastic and one of them leaves and a new one enters, then you have to deactivate the old one and activate the new one, but only then.
Hope it helps.
I use TFS 2010 and I need using TFS API to retrieve an information about work items that were deleted. There is a table [WorkItemsDestroyed] in the TFS DB that contains the information about destroyed work items. Is there any way to get that information using TFS API?
It depends on what information you want to retrieve. If you want to find out who deleted the work item then you can do that with sql (#pantelif comment).
If you want to retrieve information about the work item itself I think there is not any way to do that, either from TFS API or sql command. As described at this post, you cannot recover deleted work items:
Deleting Work Item Action Is Not Recoverable
Actually, as long as the test plan has not been deleted, there should be full history of the actual test results allowing you to recover from the deletion of a test suite...it may take a bit of time, but process works.
Try this to re-create your test suites and associated results.
Recreate the suite.
Add tests if not a query-enable suite.
From Test tab, select your suite within the hierarchy.
Create some initial results to allow you to see full history for each test. Within the test lists pane, mass-select all test results and set them to blocked.
Now when you open each test result, you will see full list of previous test results history associated to each test case at the bottom of the results window.
In other words, you need to trigger an initial result to see the full history.
For any results only carrying a single “Blocked” result, the test has not been executed. (first time the result has been made)
For tests that have additional results associated to it, identify the last known state (see the Created date column), then set it appropriately (Pass/Fail/Blocked)
NOTE: This will only work as long as the Test Plan has not been deleted. If it is simply a test suite, this should get you back up and running quickly.
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.