I have a few (~20) reviews in "Incoming reviews" section, and I would like to either move or filter out those that I did "Code-review" +2 or +1 myself. Preferably move to the other section "approved incoming reviews" or other comparable solution. Currently gerrit grays out subjects you approve, but it also grays out any other projects you post some comments. So it does not filter those efficiently, and you have to revisit every project. That is time waste.
I have tried to remove myself from the project after the approval, but such action removes approval as well.
Is it even possible?
A suggestion:
1) Click on YOUR-NAME > Settings
2) Click on Preferences
3) In My Menu add the following:
Name = Review (or other name you want)
URL = #/q/reviewer:self+status:open+label:Code-Review=0%2Cuser=self
4) Click on Save Changes
Now if you click on the new menu item: My > Review you will see all open changes you're a reviewer but don't have voted yet.
Related
I'm trying to lock/deny the option to open a new work item with specific iterations.
I tried to do it with a custom field with same value of iteration id and
<PROHIBITEDVALUES> rule.
Then I understood that its not possible because iteration-id field load only after I press the "save" button and its too late.
There any other ideas how to do it?
There is not any build-in option to hide older/specific iterations in the Work Item field.
However, you can set the security for "Edit work items in this node" to deny and they will not be able to save work items with the area or iteration selected.
Besides you could also hide the iteration node(s):
Open Project settings>Project configuration
Select the Iteration Tab
Select the iteration that you want to hide
Click on Security > Add a "Deny View" permissions for the users that
you want to hide the nodes from.
The user will not able to see the iteration in the sprint.
update:
I need help creating a "Submit Feedback" Button that essentially, would email the admin the text of the feedback the user submits. If I can do this with a workflow, I would prefer that. However, if we need to create a SuiteScript, that's OK.
I need to know how to get the button to stay on the task at all times so the user can always see it no matter what. Moreover, I then need to have the feedback sent to the admin via email. Thanks for the help everyone!
Workflow: Event Definition>On Create and On View or Update (to make sure the button always appears)
State 1: Action > Add Button (Trigger on Before Record Load)
State 2: Action > Send Email Transition: From > State 1, To > State 2, Execute On Button > Choose button created in State 1
Once you have set all the required fields for these steps, this should work. Let me know if you need anything clarified.
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.
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...