Completing associated work items after merging - possible to configure which state work items are changed to? - merge

Complete associated work items
When this functionality is Activated I would like to configure which state the linked workitems are moved/changed
Are there any possibilities for me to configure what happens to the work items that are associated?

You can set the work item state associated with the PR by prefixing the work item with the appropriate state.
Example PR Description:
Fixed user state error
Resolved: #211
More information in the following page:
https://learn.microsoft.com/en-us/azure/devops/boards/work-items/auto-complete-work-items-pull-requests?view=azure-devops#specify-the-workflow-state-of-linked-work-items

Related

Azure Devops Boards - can we block task from done if there isn't any test attatched?

We are trying to implement a new method for our QA team.
I have looked around the setting but couldn't find an answer:
Is it possible to prevent them from dragging the task to 'Done' if they haven't added a test case into it?
On the same logic - can we block the 'committed' column from them if they haven't added a bug to the task?
Thank you.
There is currently no build-in feature to help you achieve this directly.
Here is a work around for your demand:
Create a new filed named "TestCaseLinked"
Every time a Test Case is linked to the task WIT, you need to manually put a value into this field. And use the WIT rule to check the value when changing the WIT status to "Done"

How to set the Assigned To when state changes in VSTS/Azure DevOps

I have an inherited process from an Agile process. The base process had the following states New, Active, Resolved, Completed. I added several new states, so now it goes New, Triaged, Active, Development Dont, IT Testing Done, Resolved, Confirmed, Completed to better match how it flows through different people.
The process has some built in State change rules, so when it goes from New to Resolved or Active to Resolved the Assigned To changes back to the Created By person. Also when it goes from Resolved back to Active it switches the assigned to back to the Resolved By user. This works fine, the problem that I have is that these state change rules only happen for these specific states.
In VSTS online I have setup some custom rules to do different things as it moves between different states, but what I can't find a way to do is to set the Assigned To field to some other person field on the Work Item. I can set it to a hard coded person, but that is not what I want. I want to do the same state change rules that already exist for the built in states on my new states.
Here is an example of some of the rules that I have set, but I cannot find a way to set the Assigned to field to another field, i.e. Created By or Resolved By.
Use the copy value from to assign the value of one field to another:
I've just been doing a similar thing and found there's also an action setting to 'Use the current user to set the value of...'
Example of this below:

How to customize workflow in Azure DevOps Service (VSTS online)?

I've read all the MSDN docs, but cannot find a way to edit the work item transitions in Azure DevOps Service (VSTS online).
I'm trying to:
Add a custom Reason to a State of a work item. (e.g. "resolved", "won't fix")
See/edit all the existing rules about how states transition.
This is possible if you are on the Hosted XML Process model in VSTS.
Hosted XML process model concept - VSTS
When are you on the Hosted XML Process model you ask??
Well after lots of reading I found the following note on the page explaining Hosted XML customization which states
Feature availability: Import process supports the Hosted XML process model which allows you to manage customizations through updating select XML definition files of a process template. This feature is only available for accounts that have been migrated to VSTS using the TFS Database Import Service.
But since I didn't import my VSTS I'm on the Inheritance Process model.
Which does NOT currently support this feature as confirmed here in comments
#RohanDaniel #ehofman#MSFT #DevMarTechOps You are correct. Advanced workflow management, which includes restricting transitions and customizing the reasons of a transition is not yet possible in the Inheritance model. It is on our backlog to add though.
Also, if you indeed used a high fidelity migration tool and you have a Hosted XML process model, you are stuck on it. You cannot move to the inheritance model as seen in this link.
In summary then. On the Inheritance Process model in VSTS this is not a feature that is available currently but is on the backlog as confirmed by MS. However it is not planned for delivery in the next few months and a year or more from now is more likely.
In my case I also had to add addition fields and a new state on the BUG WIT (Work Item Type). This was accomplished on VSTS by customizing a process which is done by inheriting from one of the standard processes ( Agile, CMMI, Scrum ) which you can then customize.
You can add customized rules to a WIT and you can base a rule on changes to the state.... however the rules seems too limited to restrict transitions and the options to set fields doesn't have the "Reason" field available.
In fact, I came up with a solution! Which I admit is not clean as I would like, but it works.
I created three new fields: "Rules error" (Text single line), "Rules broken" (Text single line) and "Rules activated" (Boolean).
"Rules error" I put it on the main tab so I can see the error and the two others I created a tab named "Useless" in which I put them.
Now, add a rule making the reset:
Name: Reset rules
Condition: The value of equals ==> "Rules activated" ==> true
Action: Clear the value ==> "Rules error"
And then one rule per not wanted transition of states:
Name: State change - Approved to Deployed QA
Condition: A work item state changes from ==> Approved ==> Deployed QA
Action: Make required ==> "Rules broken"
Action: Set the value of ==> "Rules activated" ==> true
Action: Set the value of ==> "Rules error" ==> "Can't change from Approved to Deployed QA"
I know, entering something in the field "Rules broken" breaks this enforcement, but as this functionality doesn't exist, it is the only way I came up with when you don't have access to Hosted XML.
Neither of those things appear to be possible at the moment.
The VSTS process customisation is very different to TFS and is still evolving. #1 seems like something that might be added in a future update. But #2 doesn't seem like it would appear, as Microsoft have relaxed most of the transition rules on all the templates on VSTS by default.
This is currently not possible when using inheritance process.
You can vote for this feature request in the community: Allow specifying state transitions when using inheritance process
It's possible by creating our own custom extensions and creating some rules that disable state changes from one state to another state
I have implemented this for my org but haven't published it online..will do it soon
Here is a workaround for denying any users who are not a member of group "HighLevelManagement" to change state from Approved to Committed for PBI:
Create a new Field Called "Unlocked".
create a new rule to "Hide the Field" when the user is not part of "HighLevelManagement" as below
Create a new rule with action "Make Read Only" set to "State" when
Unlocked is False and workitem change from Approved to Commited as
below:
Now whenever a user from HighLevelManagement wants to change state from Approved to Committed he simply tick Unlocked change state and then tick back Unlocked, that way anyone from outside HighLevelManagement will be restricted to change state from Approved to Committed.

executionPriorityOrder vanishes from UI after deploying pipeline

Here is some weird behavior of ADF Author/Deploy UI that I came across. You will see the same if you try.
Open any existing pipeline in ADF, in any of its activity (e.g. my activity type is HDInsightHive) within policy block there is an option called:-
"executionPriorityOrder": "NewestFirst",
if you hover over it, you see another valid value for this is OldestFirst, so if you change this to:-
"executionPriorityOrder": "OldestFirst",
Click on Deploy. After deploying & provisioning, again open that pipeline and you will notice that now the entire executionPriorityOrder statement missing. Is it because OldestFirst is default or something?
That's correct, "OldestFirst" is the default value for executionPriorityOrder. In this property's case, the default value is not displayed. I agree this can be confusing, however the value is in fact being preserved in the defintion for your pipeline.
P.S. Sorry for the very late response. The ADF team is making a push to respond more quickly to community forum questions.

Deactivated page is available after package replication

This is the scenario (CQ5.6). Let's say there is the following node /content/geometrixx/articles, with articles inside of it. In author instance I create a package as a backup of that node. Then I deactivate article1 inside of articles, if I try to access the page I get a 404 page, that is fine. However if I build the backup package again and then replicate it, the deactivated page (article1) is available, that is, I do not get the 404 but instead the article.
Is there a way to replicate a package while preserving deactivated pages? That is, how I avoid re-activation?
Replicating package means that you are replicating every thing available in Package. Which means publish environment will have deactivated pages also. There are several ways to handle it, like:
Simplest way is to add a check in template (as first rule) to see if Env==publish && requested resource ==not activated, if so, return 404 page.
Another way is to create a script to delete all deactivated pages, and run this script on publish after page activation.
Add exclude filters in your package to exclude such pages.
I would recommend to use #1 as this is one time change and will be future proof.
should use treeactivation: http://localhost:4502/etc/replication/treeactivation.html, much safer (since you have 3 options: Only Modified, Only Activated and Ignore Deactivated)