Out-of-the-box TFS provides ability to either "Associate" or "Resolve" bug/task during check-in action.
I've added additional state "Implemented", created transition from "Active" to "Implemented", added into its "Action" value "Microsoft.VSTS.Actions.Checkin" and expect to have "Implemented" option in the list of "Check-in Action" on the "Pending changed => Work Items" panel.
I've saved updated work item type, imported it into TFS, 'refresged' team explorer... but in "Check-in Action" list there are still only "Associate" and "Resolve".
Please advise: how to add additional options into that list and implement switch of work item state.
Any thoughts are welcome. Thanks!
The checkin actions aren't item workflow states, but are used to trigger the transition of a work item from one state to another.
As a starting point, have a look at the MSDN Documentation to get a better idea of what's required.
You might also want to look at this older thread on the support forums.
The only thing I've found is that the only "resolve" action is allowed for Check-in operation. And it is only available if from "current" state you have defined "Microsoft.VSTS.Actions.Checkin" action. Some time it work's, sometime now. If you are adding few actions from one state (with different name) - they both works,... but not exactly as I want... don't know why...
Related
Is it possible to create a rule for a Task transition that would require to change the "AssignedTo" field? Does not matter to what user, just not to the same as it was before the transition. I have tried to add an "EMPTY" rule for the transition and a "REQUIRED" for the target state, but TFS denied to save such a combination stating that it is inconsistent.
Background: we have "In progress" and "In review" task states and it is required that review is done by another developer.
You could use the NOTSAMEAS https://msdn.microsoft.com/en-us/library/ms194953.aspx if you copy the original field value somewhere first so it can be compared with that rule.
Is there a field in TFS or any way to get the datetime value on which a sprint backlog task was changed to done?
I spotted an AuthorizedDate field but I'm not sure if it's out of the box or not.
Suggestions will be appreciated.
It is possible to get TFS to do this for you if your template isn't already set up to do so.
Start the TFS Process editor (Install TFS power tools if needed), connect to TFS and edit the WIT Task.
Create a new field called (For Example) CompletedDate with a suitable reference name (For example: StackOverFlow.Questions.TaskCompletedDate).
Set it to be of type DateTime.
Next go to the workflow tab and do the following for each of the transitions to the done state:
Right Click, select open details
Select the fields tab, click new.
Enter the reference name of the field you create above (StackOverFlow.Questions.TaskCompletedDate).
Select the Rules Tab and click new.
Select SERVERDEFAULT from the list of rules
On the dialog that appears, set the from field to clock.
Click OK, OK, OK to get back to the workflow.
Save the Work Item Definition.
See:
https://msdn.microsoft.com/en-us/library/ms194981.aspx
When your work item is set to done the closed date and closed by fields are set automatically.
These fields are part of all of the default templates.
Some of the older 2012 & 2013 templates did not include this for tasks and you would have to adds it', however you should use the out of the box provided fields and not create new ones. If you are reporting in this it's a nightmare if each work item type had its own way of doing things. Use the System.ClosedDate and System.ClosedBy field. You can copy the setup from the PBI or Bug work items..
I am trying to follow this article to do the same for adding a new State to a particular project's Bug work item. By default I can only see . I wanted to add a new state, "On Hold"
But I perhaps followed it wrong and ended up getting
The error says "Open Transition Active~On Hold to add at least one Reason." How do I open that transition and where do I add one reason. What is the reason it is talking about? I only want to add a new state.
Thanks for your time...
Double click the Active~On Hold Transition , select the Reasons tab and type in at least one reason.
After saving the .wit file, you must click Refresh from the Team Explorer menu in order to see changes.
In the work item editor, double click on the Transition between your Active and On hold states. Under 'Transition Detail' you should see 'From: Active' and 'To: On Hold'. Change 'From: Active' to blank so it should show 'From: '. Now save the editors, click 'refresh' from the Team Explorer menu and any new bugs you create will have 'On Hold' as an option for the state.
Once work items in a particular workflow reach a "tested/resolved" end state, I don't want them to be editable. I could enter Field restrictions on the end state for every field that exists, but that's a pain and doesn't easily support the addition of future fields. Is there an easier way?
Thanks!
Alas, I don't think there is an "out of the box" way to do this except for using the "when" clause on each of the fields or adding it to the state transitions to "tested/resolved" (as you have indicated).
I have a SharePoint list with Content Approval enabled. The business requirement is that once the new list item is approved it should stay approved despite further updates by any user.
My first thought was to handle the ItemUpdating method, and if the corresponding before property is Approved then set the after property to Approved. This doesn't work however.
In the ItemUpdating method the "Approval Status" column does not show up in properties.BeforeProperties or properties.AfterProperties. properties.ListItem["Approval Status"] and properties.ListItem.ModerationInformation.Status both show the "before" value. In the ItemUpdated method the situation is the same, except instead the values shown are the "after" values.
Is there a way in either method to identify both the before and after methods? I can work around this by creating a new hidden column that I set when the item is approved but that doesn't seem best.
Should I be approaching this from a workflow perspective?
Would this help?
http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=25
Use field's internal name with AfterProperties or BeforeProperties.
i.e. properties.AfterProperties["internal name"].
It works for me
Please refer to the following properties in the AfterProperties section for a document library.
Document libraries are a bit different than lists. the doc libraries have .AfterProperties["vti_doclibmodstat"] and .AfterProperties["vti_doclibmodcomm"].