Here's the error I was getting in VS2015: "One or more checked work items failed the transition testing due to invalid field values. Please correct the values and retry the check-in."
I had this when checking in an associated work item and flagging the item as resolved. So
Work item in in progress
Check in with this work item marked as resolved
Work item is updated to ready to test
BUT
the work item can't move into the new state as it needs additional information. In my case TFS is set to assign the bug back to the person that raised it. It was such an old bug that the person raising it had left the company and doesn't exist in TFS - hence the error.
Moral of the story - fix bugs quicker.
In my case, I was forced to do the Associate since I got the error message. When I went into the Work Item in VSTS I manually resolved it and it prompted me to set a required field. Were that required field set, the Resolve from Visual Studio would have worked.
I faced same issue while check in from visual studio.
Change the related work item as associate instead of resolve from visual studio solved my issue.
As a workaround : Create a new task/bug in your VSTS for whichever story. Then assign your check in to that work-item. That's what the error is somewhat saying... Difficult for me to decipher at first, hope this helps others.
You need to determine the task status you have created for your TASK. You should set your task state -- Development or other, You get an error because "state" is "new"
I'm using DevOps 2019 on-prem and I had 1 little update to share.
I created the Bug on the Web Portal and kept it open, added the Ticket Number for the checkin and got the above error.
EASY FIX :
Remove Ticket from Checkin
Close Ticket in Web Portal
Re add Ticket
Checkin
ALL IS GOOD.
Related
I'm encountering a strange problem. I have a workflow which triggers when an entity is created. It has the following steps.
Step 1: Update the lookup field to link to a record in the Autonumber entity.
Step 2: Set the record number field to the value of the Counter field in the Autonumber entity.
Step 3: Increment the counter field in the Autonumber entity with the value of the Increment By field in the same entity.
I use such workflows as a means of getting an Autonumber. This worked fine until I decided to import my unmanaged solution to another organisation. In this new organisation this workflow throws the following error on Step 1.
Sync workflow 'SP Electrical Autonumber' terminated with error 'systemuser With Id = 1901130da-..... Does Not Exist'
This is odd as I'm creating the entity so the workflow is set to run as the The user who made changes to the record and I've got the System Administrator profile. Further my GUID is different to the above guid and my guid exists in the database. So I'm struggling to understand where its getting this guid from.
I've checked the Autonumber record in the first step using (Select * from Filteredcal_autonumber) and couldnt find the guid in the error message anywhere there too!
So where is it getting this guid and why is it that just this workflow is throwing this error. Other entities use similar workflows for their autonumbers and they seem to work fine. Any ideas? Or places to look would be much appreciated. I've investigated this myself a lot and only posting here as a last resort as I'm really out of ideas.
I have even deleted the entire workflow and recreated it again to see if this solves the issue. But it didnt and I'm still getting this error.
I've identified the guid to belong to the installer account from the previous organisation that I had imported the solution from. Not sure why the process is looking for this guid in the new organisation. Anyone?
Ok so glad I got to the bottom of this. This is another CRM gotcha!!!
The issue wasnt with the workflow at all. Inspite of deactivating the workflow I was still getting the error. On discussing with a work colleague we concluded that one possibility where a GUID from an older organisation might have been inserted was Visual Studio. The old organisation used custom plugins and they were held in Visual Studio. When I imported the solution to a new organisation, I continued to use Visual Studio to make changes to these plugins. I continued to deploy them to the new organisation. This made Visual Studio transfer the old guids to the new organisation.
What I should have done is, in VS when you connect to a new organisation, you need to open the RegisterFile.crmregister file that you will find in the Deploy project and set any Id='[guid here]' to Id='000000-0000-0000-0000-000000000000' so that when you deploy new fresh GUIDs from the new organisation are created and stored.
To fix my problem, I unregistered the plugins, then reset the IDs in the file as above and then redeployed the plugins! Voila! Everything works now!
We have a SonarQube 6.0 server with enabled SCM plug-in. So the REST webservice returns the author for each new issue.
While this is an important information, the person who fixed the issue is also important to me. The assignee seems to be that person, however the issues are auto-assigned to whoever created them and their assignee doesn't get changed when somebody else commits a fix. (And yes, the author should fix the issues, but often they don't.)
Things I tried:
Rerun Sonar on a project that was not changed since the SCM plug-in was introduced: the author was filled with the committer, and the assignee was only filled if there is currently a Sonar user with the same name
introduced a new issue - both the assignee and the committer where set to the committer
fixed an issue with an assignee: nothing changed
fixed an issue without an assignee: nothing changed
So from that I assume if I wanted to fix an issue, I had to manually open the Sonar Website, find the project, find the issue, assign it to me, than commit. That's not really acceptable. So I assume there is some other way for Sonar to handle that information.
How do I find out who fixed a Sonar issue?
Unfortunately, you're not going to be able to do this because:
When an issue is created, it's associated with a line in a file, and assigned to its "creator", the last person to touch that line.
When an issue closed, it stays associated to its file, but loses the line association. So there's no way to attach "praise" to a closed issue because we've lost the link between the issue and the person - the line number.
On a side note, you say something about assigning yourself issues on SonarQube before fixing them. Perhaps that was in an attempt to make the "praise" association, but there's no reason to do this.
To the issue of knowing who's not fixing their issues: you can always search by assignee (and/or creator) in the Issues interface. The Issue count and age you see there should give you some idea of what's going on.
I have an existing solution that has previously had no problems. I added two new projects to the solution, completing my dev work with no problem, however when I try to check the solution in I get an error similar to the following:
C:\Project1Path\Project1.csproj: Download of item $/Project1/Project1/Project1.csproj was not completed. Perform a get operation to correct.
I get the same when I try to check in just this project. I have not tried checking in the other new project yet as ideally I want to check everything in together.
I did a Get Latest on the solution on the outside chance that that was what the error was telling me to do but to no avail.
Any help appreciated as sooner or later someone else is going to want to work on the solution.
Many thanks
Simon
I had this issue and when I ran get latest in source control it picked up a non version controlled file with the same name and asked to overwrite it.
If you get that conflict make sure you overwrite the local file.
If you don't get a conflict maybe delete local file manually and then get latest.
I'm not sure that'll work but you could try.
If this isn't resolved with a get latest, go to the actual file in team explorer. If it has a small diagonal icon next to it then right click to resolve the conflict manually. Here you can override the changes.
This is here for anyone else who may run into the problem.
In my case the file was deleted in the TFS. Undo pending changes for this file (undelete it) then try to check in again.
Note: you cannot tell if the file is delete just by looking at solution explorer.
It happened to me as well when I tried to checkin the code from TRUNK after merging from feature branch.
What I did is rolling back the change from TRUNK and merging it again.
When you in visual studio 2013/tfs2012 check in your work associated with A task you can either 'associate' or 'resolve' the task. Setting it to 'resolve' Will automatically move the task on the sprint backlog and the kanban board to 'Done'. This is Nice because AS A developer you only need to check in using the correct status and status everywhere is okay :-).
This does not Seem to be the case with work items of type 'Bug' - here I Can only choose 'associate' inside vs2013 and then I also need to manually Enter web access and set the bug to 'done'. So I'm kind of doing the same work twice.
Can I without customizing TFS work item types or the proces template get this bug status set to 'resolved' as it works with 'tasks' today - and how?
It's definitely possible - We use "resolve" with every bug (under the Agile template) because it saves such a lot of time. In pending changes, just associate the bug (type in its work item id, or drag and drop the bug into that area of the pending changes) and then you can either "associate" or "resolve" it. (After which the originator can verify the fix and close it)
I presume you're using a template that doesn't offer this facility - so perhaps diff your template against the standard Agile template and you may find the tweak you need to allow this behaviour. Does the template you are using support the "resolved" state on bugs? Perhaps it is missing?
If it is just that your bug template skips the "resolved" state, then it would be trivial to either rename the equivalent state (perhaps it's just not being picked up by the UI because it's not named correctly or not in the correct group?) or insert a new state using the WIT editor.
It's really not a good idea to set a bug as done on checkin. Has the coder verified that the completed output meets the definition of done? How can they hope to do that before they check in?
A bug, just like a PBI, greys set to done when a Development Team decides as a group that out is complete and that they have met ask quality bars.
In the Scrum template Bugs are product level items that confirm to the DoD. However you would break that bug down into a number of tasks at your sprint planning meeting and they can be resolved. The workflow for a bug is:
1) Bug created by tester as the result of a failing test.
2) Bug accepted into the sprint by the Development Team.
3) Bug broken down into tasks for at least coding and testing work.
4) Coder fixes the bug and resolves their Task. The checkin marks this task as Done.
5) Tester validates the Test Case that proves the bugs existence now passes. They mark their Task as Done.
6) The Development Team meets and assesses the doneness of the Bug against the DoD. If done they mark it as Done.
A bugs flow is different from a task.
A bug is raised (tester / user / Developer)
A Bug is fixed (Developer)
A Bug is Tested (built, Integrated to main build, deployed, Tested by Testers)
A bug is done (signed off by the originator)
is the general flow of a bug, TFS ALM assumes that the fixing and the testing would be done by 2 different roles.
if you want to change this to mirror the task work flow, you would have to alter the template
We also use the Microsoft.VSTS.Actions.Checkin action to transition a bug between Development and QA states. Developers can Associate or Resolve, and Resolve triggers the state change attempt. HOWEVER, if any fields are required in the transition, such as Root Cause, the transition will fail without any error message. This is unfortunate. It would be great if the bug popped open and said "Please enter this field." If required fields are filled in before the checkin, then the state transition happens as expected.
I'm trying to change the work flow for bugs in TFS 2013.
The default is New, Approved, Committed, Done, Removed. I would like to change this to New, Committed, Ready For Testing, Done, Rejected.
I installed Power Tools 2013 to do this, so I'm opening the bug WIT from the server and using the Workflow type. However, anytime I even rename an existing state and save, it's causing this behaviour where if I change a bug to the state I created/edited it automatically removes it from the backlog. What am I doing wrong here??
Any help would be greatly appreciated, thanks.
For anyone else who comes across the same issue, I worked out what was wrong. I had to import the Bug.xml and the ProcessConfiguration.xml. I had to add a state type for the states I changed/added to the ProcessConfig before I imported it.
You need to import the WITD (Work Item Type Definition) XML into you project using the witadmin command line application.
For example:
witadmin importwitd /f:Bug.xml /p:MyProject /collection:http://tfs:8080/tfs/DefaultCollection