I have some question regarding the VSTS Sync Migration Tool (Migration Tool for Azure DevOps) where I am using the version v11.9.31 not the latest one v11.9.47 in which I am able to migrate all the workitems along with attached, related count files and along with the history itself.
We have the below two concern. Please see below.
People are getting emailed / notified of workitems during migration
During the work items migration can we migrate the existing workitem ID itself rather than creating the new ID in the target project.
I don't have an answer for your first question, but regarding the your second question, it is not possible to have the have the workitem ID remain the same. This is because when a workitem is created, the ID is create automatically by the ADO service. If you need to retain the source ID you may want to write it to a new field on target called sourceID (you can name it anything you want).
Disable email notification:
Azure devops > Organisation > Organisation Settings > Global Notifications > Settings > select Do not deliver
To verify check the Statistics tab to see how many events were generated
Also, Go to
Azure Devops > Organisaiton > select your project > Project settings > notifications > Delivery settings > select Do not deliver and save
The only way to block emails to mention is to remove that user from Organisation > Organisation Settings > User
This way it won't allow mentions and the admin user will receive email
"XXX cannot be mentioned in Bug xxx" so before migration filter these emails to a folder to avoid bombarding of emails from devops.
Retain same id:
I don't think that's possible. The whole idea is to create new work items on the target Organisation
Related
I already have access to Google analytics provided by my client and the bigquery has been configured to the project. But i want to know if i can create jobs. How do i find the role assigned to my id ?
i want to know if i can create jobs
Below is simple way to get this:
Just open Web UI and try to switch to project of your interest
a. If you do have it in the list of available projects – just select it and then run (just in case) some simple query (SELECT 1)
If it is run successfully - you can create jobs in this project (because any query is in reality a job)
b. If it is not in the initial list – select “Display Project” and enter project of your interest and also check “Make this my current project” box. If result is successful – most likely you again lucky and can create jobs in this project (but still – run some simple query to be 110% sure
How do i find the role assigned to my id
This would be more involved – you will need to use respective IAM (Google Identity and Access Management) APIs
For example you can use testIamPermissions() API that allows you to test Cloud IAM permissions on a user for a resource. It takes the resource URL and a set of permissions as input parameters, and returns the set of permissions that the caller is allowed.
The permission you should look for is bigquery.jobs.create, but yo can pass to this API list of any permissions you want to check if you have
With our TFS 2015 source control we require developers to check-in changes against work items.
However, we've had a couple of instances where a developer has checked in against one work item within our development branch, but then when merging to our QA branch they've checked in the merged changes to a different work item. An example of this is where a bug has been created underneath a PBI, the changes in dev have been checked in against a task under the bug, but then merged to QA against the PBI itself. This causes us issues with traceability.
I've seen that it's possible to add a check-in policy of "Work Item Query Policy". I'm just wondering if there is a way to write a query that will determine if the work item of a check-in after a merge matches the work item of the source changesets? I'm not necessarily after the exact query (though it would be lovely if someone could provide one :) ), really I'm just wondering whether it's possible or not to have a query to do this - i.e. is the information available to queries in TFS?
You can't do this with the existing policies, you'd need to build a custom policy.
So, technically this is possible. You can access the VersionControlServer object through the PendingChanges object:
this.PendingCheckin.PendingChanges.Workspace.VersionControlServer
You can use that to query the history of the branch in question and grab the work items associated to the check-ins in that branch.
You can check the associated workitems to the current workitem:
this.PendingCheckin.WorkItems
You could probably even provide the option to auto-correct by adding the correct work items to the checkin upon validation.
One of my policies provides an example on using the VersionControlServer from a policy.
Newly upgraded TFS server has two user accounts created, "Project Collection Build Service" and "Project Collection Build Service (Team Foundation)". Both accounts have the same GUID (listed in the Username or Scope column). These were created by TFS and the GUID begins with "Build\" Attempts to delete either results in an error. Using TFSConfig to list user accounts, these do not show up.
To run builds, the Project Collection Build Service Accounts group must have, as a member, the Project Collection Build Service user account. Both of the accounts listed above can't be added to the group because of the matching GUIDs.
Every few hours, builds start failing with error stating
The workspace xxxx;Project Collection Build Service does not exist.
This means that the user account with the added (TEAM FOUNDATION) is in the group. If it is removed and the other one is added, builds start working again. Until a few hours later when the builds begin to fail with error stating
The workspace xxxx;Project Collection Build Service (TEAM FOUNDATION) does not exist.
Swap them again and builds start working. It appears it is applying the user account via the GUID but then doing some kind of verification based on the Display Name.
Some help pinpointing this error came from the post at http://www.codewrecks.com/blog/index.php/2016/01/15/troubleshoot-error-tf140
44-in-build-vnext-for-tfs2015/ but I can't find any other references to an issue with these accounts.
You may try to use tfssecurity /gd command to delete a server-level or collection-level group:
tfssecurity /gd groupIdentity [/collection:CollectionURL] [/server:ServerURL]
The group identity is the security identifier (SID). For more information about finding the SID of a group, see /im: Display information about identities that compose direct membership. You can also use the friendly name to delete a group.
Finally found solution at this link:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/495e59d2-d3e3-432d-be
98-1f0c358c2bc2/tf14061-the-workspace-xxxx-does-not-exist?forum=tfsbuild
After deleting all Agents and associated workspaces then adding a new agent and rebooting the server we have had no problems.
I'm trying to check in changes to TFS using VS2013. When I hit the button to submit, TFS returns the following error, "TF14002: The identity {domain} \ {oldaccount} is not a member of the Team Foundation Valid Users group."
Background: my account name has been changed to {newaccount} from {oldaccount}.
When I first started working at this company I'm almost certain I set up my TFS with my old account. But I thought I deleted all that stuff related to my old account and reset everything to my new account. My lead tech has even shown me the account mngmnt screen with my new account name. And I've been able to check out items with my new account name.
I performed the following steps to try to "clean out" TFS:
• I copied all of my changed files to a back-up location.
• I undid all changes in TFS (note that TFS has been allowing me to check out files to edit).
• I deleted the TFS entry in Credential Manager per a suggestion online.
• I deleted my Workspace.
• I even deleted my TFS server.
• I Rebooted my computer.
• I reconnected to the TFS server.
• I rebuilt my Workspace.
• I restored my changed files from my back-up location.
At this point I tried checking-in my changes again but got the same error message as above.
Any suggestions?
Note that I do NOT have access to the TFS server, much less permissions to perform any sort of admin on it (and I don't know the person who would). So any suggestions beyond simply tweaking my computer will require a trip through the bureaucratic swamp.
One possible positive (related to this issue) is that we've been informed that a number of us need to downgrade from "Ultimate" to "Professional" so if your suggestion is to reinstall Visual Studio, the upside is that I'll be doing that soon anyway.
Thanks,
Doug
EDIT:
Additional Info: I deleted everything in this folder:
C:\Users\ ...\AppData\Local\Microsoft\Team Foundation\5.0\Cache
... but I'm still seeing the error.
UPDATE 1/24/2015:
I did finally "downgrade" from Visual Studio 2013 Ultimate to VS2013 Professional, but I'm still experiencing the same error. Might there be a table in the TFS database that still has an entry for my old account that could be joining to my computer name &/or new account name when TFS goes to look up my account info when I check in my changes? I am getting desperate for an answer!
An addendum: when the sys-admins changed my account name they did not update my computer itself, so I'm still using C:\Users\{oldaccount}. I can't believe that would make a difference but you never know....
UPDATE 2/27/2016:
Sorry for not updating this sooner. I resolved this issue with the help of our DBAs:
There is a table named Constants which contains the domain part and a field named “NamePart”. The resolution was to simply update “NamePart” to “{newaccount}” from “{oldaccount}”. This table also has an SID field which is the user’s SID from the computer’s Registry. You'd only change the SID if a new login to your computer was created. In my case, there was no new login account, just a change to my login account -name-, therefore, no new SID.
And a side note, for situations when one’s email is also spelled incorrectly, there is also the ADObjects table which contains a field named “MailNickName”. This field should be updated as well when a user name is misspelled. For instance, I had the DBA update that field to change “Dug#NotReal.net” to “Doug#NotReal.net”.
Updating the Constants table is imperative to making TFS work; updating ADObjects is only relevant if an alias isn’t included to forward mail from the one email address to the other.
I found a file called VersionControl.config inside of the
C:\Users\{username}\AppData\Local\Microsoft\Team Foundation\5.0\Cache\Volatile\ folder that had my old domain username in. Changed it to my new one and it started working again.
I was having the problem with shell integration, Visual Studio actually worked fine.
I should have posted my answer (update 2/27/2016) as an official Answer. I resolved this issue with the help of our DBAs:
There is a table named Constants which contains the domain part and a field named “NamePart”. The resolution was to simply update “NamePart” to “{newaccount}” from “{oldaccount}”. This table also has an SID field which is the user’s SID from the computer’s Registry. You'd only change the SID if a new login to your computer was created. In my case, there was no new login account, just a change to my login account -name-, therefore, no new SID.
And a side note, for situations when one’s email is also spelled incorrectly, there is also the ADObjects table which contains a field named “MailNickName”. This field should be updated as well when a user name is misspelled. For instance, I had the DBA update that field to change “Dug#NotReal.net” to “Doug#NotReal.net”.
Updating the Constants table is imperative to making TFS work; updating ADObjects is only relevant if an alias isn’t included to forward mail from the one email address to the other.
The above solution did not work for a developer in our company. On of my colleagues came with the simple idea to do a "undo checkout", which worked. After that the check-in en checkout worked well again.
I am getting the following error in a TFS 2010 build:
The work item '59' could not be updated: 'TF237086: The work item cannot be saved because at least one field contains a value that is not allowed.'
Work item 59 is a basic task I created to associate with my changeset on check-in. I have done no customization to the "task" work item. I get no errors when opening the task up and changing values manually. There is nothing in the build log that gives any clues as to what field is causing the problem.
How can I troubleshoot this issue?
Something I would do in this case:
Check the build service account, there's a high chance that when the work item is associated, its ChangedBy field is updated with this account and the value is not valid. Somebody in MSDN forum suggested checking the list of valid TFS users for a work item (you can open a bug and try typing the name in the AssignedTo field) and see if this account is in that list.
Try a checkin by yourself with the same associated task and see what fields are updated (you should be able to see this in the History tab), from there you can figure out the possible fields, and hopefully can guess the one that is in trouble.
If none of this works, I can get some more details and try to repro it on my machine. We'll need to improve error message to specify which fields that are invalid.
Hope this helps.
[Update]
The cause was indeed that the build service account (NT AUTHORITY\SYSTEM) did not have permissions to modify work items. All my attempts to fix this by editing group memberships failed, but I did get the build working without errors by using an unused project contributor's account as the build service account. Changing build service account may require the old build workspaces to be renamed or reassigned.
I had the same issue, after restarting VS 2015 IDE and entering credentials to my account on the TFS I was able to get rid of the errror.
After changing the build service account, I got a new error
The working folder xxxx is already in use by the workspace
1_1_SSSSSSSS;NT AUTHORITY\SYSTEM on computer SSSSSSSSS.
The solution to that issue is to use the TF utility to delete the workspace(s) associated with the SYSTEM build account. I had to copy the TF utility from my Laptop over to our server to run it.
See TFS Build Service Account change causes Build Failures - “Working Folder in use” Failures
Got the error on a long running build system where the user accounts had not changed.
found the WORKSPACE ID in the build log ran
tf.exe workspaces /owner:*
to confirm the workspace was on the build server and then ran
tf.exe workspace /delete 9_1_BUILDSERVER;OURDOMAIN\TFSBuild
to delete it, queued another build and no further problem.
If you changed process type, can throw this exception. Please correct your process type. My problem solved with the action.