I have created a new Bug template on Azure Dev Ops under /_settings/work-team?type=Bug&_a=templates, to allow pre-population of 2 fields on a bug ticket with templated headings. We have this working with our on-prem TFS 2019, and users know to click ... > Templates > New Bug. I'm trying to replicate this over into ADO to keep tickets consistent, but when I click ... for the context menu in ADO, Templates don't appear.
TFS:
ADO:
How do I get the Templates context-menu item to show on new tickets?
This was resolved by adding myself as an explicit user to each team for which I want to use the templates. Thanks to wade-zhou-msft for the tip-off.
Related
We moved from TFS to Azure DevOps and during that move all of the custom fields we'd created in TFS did come over to Azure but I haven't been able to find a way to add new fields to the work items. I can still use the process editor in visual studio to add the data points but can't get them to show on the UI.
Example: I added a "Deploy Status" property to Bug work items. In Azure I can query to show that new field and I can set the new field by right-clicking and editing the Bug. What I can't do is get the field to show within an individual Bug.
I have tried adding the control to the layout via the process editor.
Any help is greatly appreciated!
Host Details:
OS Editon: Azure Devops server 2016
OS Build: 1607
Azure DevOps Details:
AZ server: 2019
The issue:
For one Team Project, we are requiring to have three different sub-area paths so we can place work accordingly for each team Properly to follow it.
The three sub-areas were created as follow:
and visible are visible from Bords:
But, and here the issue, the Button for creating New Work Item now is Disabled, as shown below:
Also
How could re-enable this button?
We use this button at daily basis to create New Tasks or as required, is so weird that enabling one functionality we lost other.
It’s possible your workflow has the work item disabled. Check your process and see if the work item type is disabled. Also on the ribbon next to View as Board, hover and click, it will give you a more detailed error message.
If the work item is disabled you will see this message.
Solved by myself
Hello Martin, thanks for reaching me out so swiftly,
I did found the issue, due to a lack in Azure DevOps documentation didn't know that when creating a new Team Project have to create the extra teams within the Project before anything else, and then is that can proceed to add define the sub-area paths in the Boards Section and then is when is possible to have First multiple teams within a team project and Second have enabled the Work Items Button for each team sprint:
See for example this MS official documentation how they don't make any clarification of it: {{ https://learn.microsoft.com/en-us/azure/devops/organizations/settings/about-areas-iterations?view=azure-devops }} :
Also here {{ https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops&tabs=browser }} :
So MS docs miss that point completaly!
Solved each team is an independent unit and for that each will have their own setup,
Once that is corrected all works fine
I have projects in different AzureDevops instances created at different times.
In my current project the build pipeline has the New Yaml Pipeline Experience. My old projects have the old visual creation experience. Is it possible to toggle between the two views?
If so how do I go from the New YAML pipeline to the old view?
This enable a preview link looks promising but the NEW YAML pipeline creation is no longer a toggle option for me
You can still create pipelines with the visual editor with the new YAML Pipeline features turned on. Its easy to miss the option though. Just create a new pipeline and then at the bottom of the page click the link for the classic editor.
Is it possible to toggle between the two views?
If what you want is convert the current pipeline which is using YAML to view as Classic editor, sorry to say, no, we did not support this toggle between YAML and Classic Editor until now.
Now, we only support toggle the pipeline that code with Classic editor to YAML by using the "View YAML" button. But the reverse is not possible.
But I thinnk it would be a good feature that make configure in pipeline more convenient. Users can free to toggle between YAML and Classic Editor. You can raise this feature suggestion to our official Suggestion Feature forum, our Product Group and PMs will reviewing these ticket regularly, and consider to take it as our Roadmap.
I have Eclipse Neon with TFS plugin
When I check pending change and I relate to work item
The problem is that the Check in Action by default is Resolve and not Associate
How do I change the default?
All I found online is about visual studio which didn't help me.
(Registry not worked HKEY_CURRENT_USER\Software\Microsoft\VisualStudio**11.0**\TeamFoundation\SourceControl\Behavior #ResolveAsDefaultCheckinAction = "False")
Unfortunately, this could not be achieved in team explorer everywhere(TFS Eclipse plugin) for now.
As a workaround, you could edit the Work Item Template definition for the types of work items you are using (Bug, Task, etc.). Then remove the Check-In Action from the Work Item Template (WIT). Once the WITs have been updated into your team project this will be available for all users. Now when you add a related work item, the only option available is Associate. However, this solution has some pros and cons. Below is a few to consider:
Pros
This change only has to be made the Team Project and nothing has to be done on the clients.
If your team not resolve the work item, removing this option is not a big deal.
Cons
This would need to be applied to all current Team Projects and would
need to update the Process Template for future Team Projects.
This removes the Resolve option for users, so there is no way to perform this action anymore.
More details about how to remove resolve option, please refer DaveShaw's answer in this question: How to disable auto done status for task in checkin
Is it possible to add members in bluemix track&plan with read-only access?
I want to limit the number of people who can add/modify work items into my project.
I understand your question that you want a more fine-grained access control for project members.
Can you not allow project members to edit work items? A short answer is no.
Check official website: https://hub.jazz.net/docs/projectadmin/
Project members have the fewest privileges and responsibilities. They can do these tasks:
- Add and edit work items
- Create Git branches for Git projects
- Create tags for Git projects
- Push and pull source code from the repository
- View and edit pipelines
- Add, edit, delete, and run pipeline stages or jobs
I think project members should have the access right to edit work items.
Bluemix track&plan is based on RTC(Rational Team Concert). I've been using RTC for team's project development for several years. It can be disturbing when someone removes a tag used in a query or changes work item to an incorrect status.
But the essence of track&plan is for team collaboration. Work item is critical to provide transparency and real-time status. Everybody on the team should have the right to add comments to the work item. My best practice is to use daily scrum meeting to review team dashboard and validate the work item status.
In real life, I seldom see team members deliberately update work items that don't belong to them. Instead, scrum master needs to motivate team to provide more update to the work items.
If you want to share the status to a stakeholder who's not in the project team, one doable option is to set your project as "public".
Try to access the link I created: https://hub.jazz.net/ccm51/quickplanner/jazzhub.html#items:projectId=_9b859SQ7EeesKZSRjqyxIQ&serverId=hub.jazz.net&planType=allwork&allIterations=true
Steps to set up your project as public:
1. Navigate to the Track&Plan dashboard. Click "Settings" icon
2. De-select "private" project checkbox & save