Attribute Customisation: Caluculated Value Script Trigger for Status Change
Dear Team,
Usecase:
We would like make handover of workpackage between the teams easy.
With current setup of ours, Team Leader of One Team, cannot just change the other Team by using filed against, if fields like Owned by,planned for are already set in his Team.
He has set this un assigned and then change the Field against.
To handle this, we are currently looking at the Attribute customisation- Caluculated script,
Where in we provide action-Reopen, Changes state to New.
when above operation is done, Set Owned by,planned for and estimation to unassigned/Default.
Issue here is:
- Have added Status to Owned by Dependencies(Already default dependence like Target,Category)
But, i don't see script triggered for state change and also on every save as stated in below article
Could you please help in below:
- Whether script gets executed for every change?
- what happens if we have multiple Dependencies?
- adding status to attribute as Dependency, will trigger script at all?
Below is sample script:
dojo.provide("com.acme.providers.script.HandoverOwnedby");
dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");
/**
* @see https://jazz.net/wiki/bin/view/Main/AttributeCustomization#Using_scripts_for_attribute_cust
* @see https://jazz.net/wiki/bin/view/Main/AttributeCustomization#API_Example
*/
(function() {
var doDebug = true;
var scriptname = "HandoverOwnedby";
var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;
dojo.declare("com.acme.providers.script.HandoverOwnedby", null, {
getValue: function (attribute, workItem, configuration) {
debug("Start");
var workFlowTypevalue = workItem.getValue(WorkItemAttributes.TYPE);
var workFlowStatevalue = workItem.getValue(WorkItemAttributes.STATE);
var workFlowAction=configuration.getWorkflowAction();
var plannedForValue = workItem.getValue(WorkItemAttributes.PLANNED_FOR);
var complexityValue = workItem.getValue("com.ibm.team.apt.attribute.complexity");
var ownername = workItem.getValue(WorkItemAttributes.OWNER);
debug("State" + workFlowStatevalue);
debug("Action" + workFlowAction);
debug("Type"+ workFlowTypevalue);
debug("plannedForValue"+ plannedForValue);
debug("complexityValue"+ complexityValue);
debug("ownername"+ ownername);
if(workFlowType === "com.ibm.team.apt.workItemType.story" &&
((workFlowAction === "com.ibm.team.apt.storyWorkflow.action.a14")
|| (workFlowStatevalue === "com.ibm.team.apt.story.idea") ))
{
return "_YNh4MOlsEdq4xpiOKg5hvA";
}
return ownername;
function debug(display){
if(doDebug){
console.log(scriptname + " " + display);
}
}
}
});
})();
Accepted answer
No, you can not:
we can only fetch the current state and what action user has tried NOT the Target State
You can not fetch the action the user has selected in any of the java script attribute customization providers except conditions. This has been made pretty clear by
since 4.0 M1 getWorkflowAction() returns a string that is the id of a workflow action currently selected by the user. This action will be executed when the item is saved. If the user has not selected any action this method will return null. Note: This method works only when used inside a Condition script, the return value will always be null when this is used in other customization script types.
The rules for triggering the scripts can be found here
If you configure a Script-based calculated value, the script will be executed in three cases:
* When a work item is created, the script is executed
* When a work item is saved, the script is executed to recalculate the value.
* When an attribute which the current attribute depends on is changed, the value of the current attribute is recalculated. Depending on the presentations of the two attributes this may not work in all cases.
Note that this does not mean that the script is triggered only once.
If you want to be able to access the action - and I am not sure that will help here, please create an enhancement request.
You can do this in follow up actions if you want to. They can detect a state change. It would be nice if there was an easier way to participate in a state change, and to allow resetting values, so that it was only one save, but the rules get very complex, I guess.
Since JavaScript is a convenient backdoor in cloud hosted environments, even more users are interested in this, because they can not deploy Java extensions.
My final statement would be that I can see, why users want to do what they want to do, but I can also clearly see that they often do not reflect on what they are doing and customize their environment to death. We actually have already had customers running into performance issues due to customization and this makes development even more reluctant to allow users doing this - especially making it too easy for them and their management to throw in the next automation to fix what is an organizational problem, or just incomprehensible complex workflows that should really be reviewed and and made leaner.
One other answer
I must have answered this answer 50 times already in this forum. This is hopefully the last time.
There is, as far as I know, no way to detect a workflow action is selected in calculated values Java Script.
So what you are trying is not possible. The state change only happens as part of the save and thus you can not do what you want.
Comments
i have read your previous posts,
below is from IBM Documenation:
If you configure a Script-based calculated value, the script will be executed in three cases:
When a work item is created, the script is executed,When a work item is saved, the script is executed to recalculate the value,When an attribute which the current attribute depends on is changed, the value of the current attribute is recalculated. Depending on the presentations of the two attributes this may not work in all cases.
When a work item is created, the script is executed,When a work item is saved, the script is executed to recalculate the value,When an attribute which the current attribute depends on is changed, the value of the current attribute is recalculated. Depending on the presentations of the two attributes this may not work in all cases.
in my case, save operation doesnt trigger this at all. But only for Dependencies that to not for "Status" Dependency.