I have an outstanding module that I need to remove Quick Create functionality from record-creating actions, to use the New Record pages. I understand the process on new Subpanels, but when I try to apply that process to actions inside the activities subpanel, they do not work consistently. Is there something different that I need to apply to when I work within the Activities subpanel?
Related
in my sprint taskboard i want to style my tasks based on their parent PBI/bug priority and not having to set a priority for each task. is it possible?
As of this time, however, there isn't a built-in feature to set fields or styles of work items based on their parent fields or styles. Here is a feature request.
If you don't mind extra work, you can get and update fields of the work items through Rest API, and use automation tools such as Power Automate to let the script to run automatically when the a work item is created.
We are using Azure Devops Server. When a bug is created, I would like to create a child task automatically. The task does not need to have any particular properties, it just need to be created with default values and have a default name like "Placeholder" or something like that.
I have already encountered some different ways of doing it, but neither of them seems to be well suited for me:
The extension 1-click-child-links could be used to create a child task by clicking a button in the context menu after creating the bug. This will of course work, but it would be even better if it could be done in the background ensuring the task to be created even if the user forgets to click the button.
As I understand it, using the Microsoft Flow software tasks can be created in the background when creating a bug which would be exactly what I'm looking for, but it would be nice to find a simpler way of doing it without installing a complete software tool.
I've learned that it is possible to hook into different events by using service hooks (https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops). There are a couple of standard integrations, but neither of them can be used to solve my case. So using this method, I guess I need to develop a custom service creating the task?
Is there a simpler solution to achieve my gool or do I need to stick with one of the solutions above?
As a workaround , we can set Azure Logic App, select When a work item is created"as trigger, and then select Create a work item as action.
Make sure to set the Link URL to the “When a work item is created” URL and set the Link Type to Hierarchy-reverse to create the Task as a child of the Bug item. Please refer to the settings below:
Save the Logic Apps Designer, and then when the bug item is created, the child task named Placeholder will be automatically created.
I have two questions about the customization of a process in VSTS
Is there a simple way to make the fields conditionally read-only, visible as simple as we make it required? (simpler than creating a new component)
Is there a way to control the workflow of the new states, to forbid removed items to turn into done without going back to new
Is there an example of gridcontrol, like the test case steps, to download and make a new control.
For your questions:
Is there a simple way to make the fields conditionally read-only,
visible as simple as we make it required? (simpler than creating a new
component)
No, read only (Assign value rules) is not available for VSTS (Inheritance process model). You can only (de)select it as Required or use custom rules to conditionally change the field as read only.
Is there a way to control the workflow of the new states, to forbid
removed items to turn into done without going back to new
There are no such settings/configurations for that. But you can develop an extension for a new Save button to check the work item revisions.
Is there an example of gridcontrol, like the test case steps, to
download and make a new control.
For VSTS work item custom control, you can refer Add a custom control. And it also shows related extension Multivalue control.
I'm trying to add a new state to the user story Work Item type in VSTS. To do this I follow the instructions outlined here:
https://www.visualstudio.com/en-gb/docs/work/process/customize-process-workflow
However, when I get the states page the "+ New state" option is greyed out and I cannot click on it. I am a member of the "Project Collection Administrators".
Can anyone tell me how to enable the "+ New state" button?
So VSO has this Hierarchy like there are Processes which can be considered as your SDLC ( Agile, CMMI and Scrum). These are System defined processes and we cannot edit them. And Each Process can have many number of Work Items associated with it. System level process cannot be edited meaning you cannot create, edit, create state for a system process. The work around is to create a Inherited Process with the Available System Processes, which will also inherit the Work Items. This inherited process can be edited (you can create, edit, create state for the work items available in this inherited process). So keep in mind while inheriting from any process, for which work work item you want to add state and create a inherited process from that parent process.
Please follow this link to create a inherited process : https://www.visualstudio.com/en-us/docs/work/process/manage-process
Also keep in mind that whatever project you create has to be based on the inherited process so that the changes that you make in the customization is available at the Work Item form level.
Hope this helps.
Thanks,
Bhadhri
I made a spreadsheet that was intended to be shared with a small group of contributors, each one with a full edit permission over only one respective sheet. I built a main sheet that was supposed to compute the information passed by all the others collaborator's sheets and make an instant update in it.
When I, as the owner, make any changes on those particular sheets, the main one works like a charm. But when someone else changes the same thing, nothing happens.
Is this something that should already be working?
I assume you're using the onEdit simple event handler, which means that the script is running under the permission of who's making the edit. Therefore, if the user is not allowed to do something, the script will not be allowed either.
To fix this you should use the installable on edit trigger instead. Just rename your onEdit function to something else e.g. "installableOnEdit", so it's not triggered as a simple handler, then go to the menu "Resources > Current project's triggers" and set up a trigger to run your on-edit function on Spreadsheet edit events.
By doing this, the trigger will always run under your account, which should have the required access to modify the protected sheets.