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!
Related
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.
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 am using power automate for Azure DevOps integration. Here is what I want to achieve. I want to create a new work item when an email arrives in a project but in a specific Area Path for the team.
I am providing Area Path and Iteration Path in my flow configuration, but when the flow triggers, it creates work item both in Project Backlog and Area Path backlog, where as I only want it to create the issue in the specific Area Path.
Can someone kindly help? Thanks, Bee
At the moment, here is how I resolved this duplication issue.
Provide all the necessary configuration in your workflow.
Include your area-path in the workflow
Provide a unique parent-id you want to link your work-item. Feature or an EPIC.
Seen the screenshot below.
After I provide a unique parent/child relationship, it stopped creating duplicate backlog items in my Project backlog and area path backlog.
Hope this helps everyone.
Thank you
I am new to azure devops and devops field. I am exploring myself in azure devops, where learning boards. I I was confused while updating the status of my work item. I was assigned with a task (example: create a login page. Now i went to azure boards and its allowing me to edit the title and priority fields. Those are already set by my higher levels. I only need to add details like time efforts, status). What security is our team missing to achieve this?
Also i need to move the work items from one stage to next stage(Todo to completed) via VS2017. How to achieve that. Now i am currently going to devops portal and drag and drop the workitems to next columns.
If you have permission to edit a work item, you can edit any field on the work item. This is by design. Whether it's a limitation or not is up to you to decide.
You can update the work item state from Visual Studio by linking it to your commit in the team explorer. Refer to the documentation.
I'm having problem with deploying changes to Sitecore item. I've made changes in the template item in Sitecore. All changes of Sitecore items are stored in TDS. During the build TDS generates an update package, then I install this package using Sitecore UpdateInstallationWizard during deployment.
The problem is that I've already deployed several builds, and just found out that changes are not applied to this template item: I've removed one field from the item, but it still appears, also I've changed another field value in the _Standard Values but it does not change after deployment.
Could you please help me to find the cause of this issue? Is there any way to review what items are in the package?
UPD: I've renamed package into zip and was able to find the template item itself and standard values for the item in the addeditems folder. As I understand it right it should mean that the item with all the changes is in package, but for some reason they are not applied.
By default, TDS will NOT remove anything from Sitecore. You need to setup the child item synchronization settings and enable removing/recycling items in the build property page for the target environment. Please see:
http://hedgehogdevelopment.github.io/tds/chapter4.html#deployment-properties
http://hedgehogdevelopment.github.io/tds/chapter4.html#build
http://www.hhogdev.com/help/tds/deploymentproperties
For more information. I recommend that you use the deployment property manager window to make sure your templates are set to "Always". Tell TDS to put items in the recycle bin in the build property page and backup your target database before trying this for the first time. Once you get the hang of the deployment properties, it is pretty easy to manage.
You can review the actions applied from an .update package within the update installation wizard itself, right after applying the package. Click the button labeled "Installation result>" and try filtering the list to look for warnings and errors related to your item.
Another option is to review logs located at ~/temp/__UpgradeHistory/ folder. In particular, I would look at the messages.xml file.