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
I am using NSPersistentCloudKitContainer, not sure if that's the cause of my issue or CloudKit generic behaviour. The sync setup works fine so far. I am now adding a new feature, causing some an issue:
I have an entity Item, which can be put in a Group. Relation in CD is to-one and optional. Works fine on device: I can set and remove group, everything is persisted.
But CloudKit just ignores when I remove the group. It does not complain, just ignores it. No matter if remove happens from Item, Groups or both sides. On next download it’s back in a group. Is it just a bug in NSPersistentCloudKitContainer? It’s possible to nil fields on CloudKit records, right?
What I see in CloudKit dashboard:
• Group field on Item is of type String.
• A fresh Item record, never assigned to a group, does not have the group field.
• As soon as it gets a group field, I can’t get rid of it. Emptying the value causes to crash.
When I get the CloudKit record on device, it does not even have the group field. So I can't manually reset it. It only shows the Group field in the CloudKit dashboard. I guess the container handles the relationship internally and only maps it during sync.
Is there any way to properly handle this?
Am not facing any issue but asking for general understanding.
When does the mixinType cq:LiveSync gets created?
One my AEM site, MSM works fine and ALL live copy pages are set with cq:LiveRelationship mixinType as expected.
Some pages have cq:PropertyLiveSyncCancelled and corresponding cq:propertyInheritanceCancelled property tells which all properties are cancelled. Its clear cq:PropertyLiveSyncCancelled is set when someone cancels inheritance against a property.
But few pages have cq:LiveSync property set and many dont. Trying to understand what action sets this property? and what impact it has on MSM?
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.
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.