How to pass value of a field from Parent Work Item to Child in Azure DevOps - azure-devops

I need to write a rule to copy a field's value to child work item(User Story) from parent work item(Epic) in Azure DevOps. But I cannot find a way using Work item's rule settings in Process.
How can I set the field in work item when parent is set.

There isn't a built-in feature can pass value between different work items. The rule only applies to the same work item. For example, we can set a copy rule to copy the value from one filed to another within the same work item.
See Rules and rule evaluation and Add a rule to a work item type for details.
The only way I can think of is writing a script by calling the Get Work Item REST API to get the value of the filed from parent work item, then calling the Work Items - Update REST API to update the child work item. Then setup a trigger to run the scripts once the parent work item is updated.

Related

How to bring dropdown at top

I'm not getting this dropdown in front as i have created a custom control combo of tree behaviour.
By reference to this doc: Add a custom field to a work item type (Inheritance process), we can add a custom field to support tracking data requirements you have that aren’t met with the existing set of fields.
Currently, the field Area Path and Iteration Path are existed datatype as Tree path, but their value are defined in Project configuration page and Team configuration page by reference to this doc: Define area paths and assign to a team and Define iteration paths and configure team iterations.
However, tree type is not available in new field, as below.
In addition, this is indeed a good suggestion. You can create a suggestion ticket here. The product group will review these tickets regularly, and consider take it as roadmap.

Prevent users from creating Work Items that have no parents in Azure Devops(VSTS)

I want to prevent users from creating work items(tasks) directly. Tasks must only be created by using add child option in a User Story and not directly. Is it possible?
Prevent users from creating Work Items that have no parents in Azure Devops(VSTS)
There is a workaround but not full solution, you can check if it work for you.
You can create a rule for the task in the process.
Organization Settings->Process->click Your custom process->click Task->Rules->New Rule:
Then we create the task directly, you will get the error:
TF401320: Rule Error for field Related Link Count. Error code:
Required, InvalidEmpty.
You have to add Related work before you save this task. But at the moment we could not limit the link type of Related work to be only Parent.
Hope this helps.
It is not perfect, but this is my workaround
Another workaround: using two rules
when related link count =0 clear value of Parent link custom field which is required
when related link count =1 set Parent link field = Yes

Run workflow over all entities to copy data from one field to another

I'm in a situation where i need to add a default value "blank" to my "Two Options" field. Since I cannot set a default value of "null" to an already created Two Options field, I though of creating a new custom field of type "Option Set" and add the same two options Yes/No in addition to setting the Default value to Unassigned.
I need to create a workflow that copies the old values choices into the new field. I understand that I can't simple equate the values of two fields of different type but I'm going to do that with Check conditions to set the new field value corresponding to the old field value.
I'm not sure how to run this workflow against all the existing records in my CRM online with no codes. Is that possible ?
Without using code or custom tools your best options are:
Do an advanced find, select all the records in the view and run the workflow - this will run the workflow against every record. You can view up to 250 records at a time (check personal settings to change this) so this might work for you.
Export all the data to Excel, make the change in Excel in bulk. Reimport the data. This way you don't need workflow at all.

In which order are workflow items processed?

I have a number of workflow items on cases in SuiteCRM.
How can I determine the order in which these items are processed? In my situation, I am setting the priority of the case based on the values of some integer fields. However, these integer fields must first be populated based on the values of some dropdowns.
How can I make sure they are populated in the correct order? I can't see an order of execution with the workflow items.
Workflow simply pulls the workflow items to run using get_full_list which will just give the items in whatever order the database returns them (probably by id).
The alternatives are to add a new hidden flag field to the case to signify that the values have been set then check this in the workflow conditions.
Allowing setting a priority for a workflow would be a good addition however and I've added this on the SuiteCRM GitHub: https://github.com/salesagility/SuiteCRM/issues/280

Detect when a record is being cloned in trigger

Is there a way to detect that a record being inserted is the result of a clone operation in a trigger?
As part of a managed package, I'd like to clear out some of the custom fields when Opportunity and OpportunityLineItem records are cloned.
Or is a trigger not the correct place to prevent certain fields being cloned?
I had considered creating dedicated code to invoke sObject.Clone() and excluding the fields that aren't required. This doesn't seem like an ideal solution for a managed package as it would also exclude any other custom fields on Opportunity.
In the Winter '16 release, Apex has two new methods that let you detect if a record is being cloned and from what source record id. You can use this in your triggers.
isClone() - Returns true if an entity is cloned from something, even if the entity hasn’t been saved.
getCloneSourceId() - Returns the ID of the entity from which an object was cloned.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_getCloneSourceId
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_getCloneSourceId
One approach, albeit kind of kludgy, would be to create a new field, say original_id__c, which gets populated by a workflow (or trigger, depending on your preference for the order of execution) when blank with the salesforce id of the record. For new records this field will match the standard salesforce id, for cloned records they won't. There are a number of variations on when and how and what to populate the field with, but the key is to give yourself your own hook to differentiate new and cloned records.
If you're only looking to control the experience for the end user (as opposed to a developer extending your managed package) you can override the standard clone button with a custom page that clears the values for a subset of fields using url hacking. There are some caveats, namely that the field is editable and visible on the page layout for the user who clicked the clone button. As of this writing I don't believe you can package standard button overrides, but the list of what's possible changes with ever release.
You cannot detect clone operation inside the trigger. It is treated as "Insert" operation.
You can still use dedicated code to invoke sObject.Clone() and exclude the fields that aren't required. You can ensure that you include all fields by using the sObject describe information to get hold of all fields for that object, and then exclude the fields that are not required.
Hope this makes sense!
Anup