It's all about the answers!

Ask a question

Why workflow action is not working in "Condition" based script?


Mohanraj Ragupathi (54418) | asked Aug 11 '15, 6:06 a.m.
  Hi
Basically we have a "Defect" in "New' state. Based on the "customer shared" attribute ("Yes" / "No") value I have to allow the engineer to save "Set Customer Reject" (for Customer shared defect) and "Reject" (for internal defect). So I need to check if "Customer shared" attribute is "yes" and the user directly move the defect to "Reject" state, the script shouldn't allow them to save the workitem.

if *customer shared = yes" (Valid Path is)
New (state) ==> "set custReject" (action)==> Customer Reject (state) ==> "set Reject" (action)==> Reject (state)

If the user follow the below
New (state) ==> "set InternalReject" (action)==> Reject (state) the script shouldn't allow them to "save" it and throw error message.

To implement this, I have a "Readonly" field - "actionbaseval" with "Enumeration" - false (default) and true.

actionbaseval field is updated based on "SetOEMbase_Action" - calculated value script

==== ==========******************************************************========================
dojo.provide("com.visteon.workitem.rejectbydesign");
dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

(function() {
var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;

dojo.declare("com.visteon.workitem.rejectbydesign", null, {

  getValue: function(attributeId, workItem, configuration)
  {

  var workitemstate = workItem.getLabel(WorkItemAttributes.STATE);
  var OemShared= workItem.getLabel("com.visteon.OEMshared");

//    console.log("worktem state is " + "workitemstate");       
//    console.log("worktem oemshared is " + "OemShared");       

  if(OemShared == "Yes")
  {
    if (workitemstate == "Reject")
  {
      // action is reject by design
         return true;
      }
   }
        return false;
  }
  
});
})();
==== ==========******************************************************========================
we have a conditions based script "chkoembase_action"

==== ==========******************************************************========================
dojo.provide("com.visteon.workitem.oemrejectbydesign");
dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

(function() {
var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;

dojo.declare("com.visteon.workitem.oemrejectbydesign", null, {

  matches: function(attributeId, workItem, configuration) {

  var OemShared= workItem.getLabel("com.visteon.OEMshared");
  var workitemstate = workItem.getLabel(WorkItemAttributes.STATE);

  var action= configuration.getWorkflowAction();
//    console.log("worktem state is " + "workitemstate");       
//    console.log("worktem action is " + "action");       
//    console.log("worktem oemshared is " + "OemShared");       

// name="set Reject"    id="com.ibm.team.workitem.defectWorkflow.action.a5"
// name="Set intReject" id="com.ibm.team.workitem.defectWorkflow.action.a6"

  if ((action == "com.ibm.team.workitem.defectWorkflow.action.a6")&&(OemShared == "Yes"))
  {
     return true;
  }
  return false;
  }
});
})();
==== ==========******************************************************========================
Under "team Configuration" ==> "Operation Behavior" ==> "Save Work Item (server)" ==> "Required Attributes For Condition"
chkoembase_action (condition) is mapped to "actionbaesval" required attribute.


The above script is working fine and throwing error, if we move the workitem from "New" to "Reject" directly if "Oem shared == yes".

If we move the defect from "New" to "Customer Reject" also working fine.

But from "Customer Reject" ==> "Reject" state is throwing error. Why this is happening? any help.

One quick clue, if we make "Oem shared == no" it is allowing me to save in all states. That means "condition" is always returning "false".

Accepted answer


permanent link
Nate Decker (37813059) | answered Aug 11 '15, 9:20 a.m.

At first glance, there is one thing that I notice that is different in your script than the examples here:

https://jazz.net/wiki/bin/view/Main/AttributeCustomization

Your "matches:" function has the "attributeId" argument, but the examples show that you don't use it for condition scripts. I have one condition script implemented in my environment and I'm not using it. I'm not sure if this is the issue or not so I'll scan some more and see if anything else jumps out at me.

Nothing else is really catching my attention, so try removing that argument and see if that does anything. I'm assuming that because you have those commented log statements, you've at least verified that the attributes have the expected values.

I do have an architectural question for you. It sounds like you are saying that there is a "customer shared" attribute and you are using this attribute to set another read-only attribute. Then you are using that read-only attribute in the condition script. Why not just use the original "customer shared" attribute? I'm not sure I understand what you are gaining by having that extra attribute to keep track of.

As another note, if you can't get this working with a Condition script, you could try a validator one instead. A validator doesn't just return true or false, it returns a "status". The status can be either Ok, Warning, or Error. You can also return a message along with that status. Basically, it's more powerful than just a condition script.

If you still can't get it working, post here again and I'll actually deploy your code on my sandbox and see what it does.

Mohanraj Ragupathi selected this answer as the correct answer

Comments
Mohanraj Ragupathi commented Aug 12 '15, 9:21 a.m.

quick note on validator script: For the above case I think "validator script" will not work.
Because the script should restrict the user if defect state is moved from "New" to "Reject" directly in case if the defect is customer visible.
In this case, the valid flow is "New" ==> customer reject" ==> reject.

This can be tested only through action flow. Please let me know if you have different thought.


Nate Decker commented Aug 12 '15, 10:25 a.m.

I think I see what you are saying. The limitation with Attribute Customization is that you cannot see the previous state like you can in an operation behavior. So if the user is setting the state to "Reject", you can't see whether the previous state was "Customer Reject" or "New".

This is probably where the extra attribute you were talking about would come into play. You could use that attribute to capture whether the work item ever entered the "Customer Reject" state. So, for example, the attribute could have a default value of 'false', but then once the work item enters the Customer Reject state, you could set the attribute to 'true'. Now, your validator script can look at that attribute to see whether the work item is coming from the "Customer Reject" state or the "New" state.

If you had that attribute, it seems like you could do this with a validator script. Though you would probably need that for the condition script too, so I am still not seeing why you couldn't use a validator script instead of the condition script. The condition should have the same limitation.


Mohanraj Ragupathi commented Aug 14 '15, 8:52 a.m.

Now I tried with validator script and the error message is
return new Status(Severity["ERROR"], "Customer Defect can't be rejected by You");
 I have configured the Attribute Validation precondition inTeam Configuration - Operation Behavior, for Everyone role.
Now I am able to save the WI and see the "error" message on the attribute value but to "hover" the cursor over the icon to see the error.
How to stop "save" WI ?. Our basic intention is "stop" the user to save the workitem for wrong condition.
Do we need to set/check anything @ server level?




Nate Decker commented Aug 18 '15, 10:26 a.m.

Mohanraj,

To get the validator script to actually block and prevent the save, you'll need to enable the Operation Behavior (precondition), "Attribute Validation". You'll need to enable this precondition for all applicable roles.

One other answer



permanent link
Mohanraj Ragupathi (54418) | answered Aug 12 '15, 8:41 a.m.
edited Aug 13 '15, 2:26 a.m.
Hi Nate,
            Yes that is a nice catch.. I corrected it now.

The issue with the script is solved and expected result achieved.

I wrongly set the "Default" value for the readonly  field "actionbaseval" and I remove the readonly option. So that the "Unassigned Literal" comparison is happening while click on "Save" button.
Now the script is corrected.

As you suggested I have changed the script to use "OEMshared" field instead of extra readonly field "actionbaseval".

For other's benefit.
"OEMshared" - field is updated through customer java API script (false or true) at the time of defect creation.

Conditions based script "chkoembase_action"

==== ==========******************************************************========================
dojo.provide("com.visteon.workitem.oemrejectbydesign");
dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

(function() {
var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes;

dojo.declare("com.visteon.workitem.oemrejectbydesign", null, {

  matches: function(workItem, configuration) {


  var OemShared= workItem.getLabel("com.visteon.OEMshared");
  var workitemstate = workItem.getLabel(WorkItemAttributes.STATE);
  var action= configuration.getWorkflowAction();
// console.log("worktem state is " + workitemstate);       
// console.log("worktem actionval is " + action);       
// console.log("worktem oemshared is " + OemShared);       

  var returnResult = false;

// name="set Reject"    id="com.ibm.team.workitem.defectWorkflow.action.a5"
// name="Set intReject" id="com.ibm.team.workitem.defectWorkflow.action.a6"

  if (action == null)
  {
    returnResult = false;
  }
  else if ((action == "com.ibm.team.workitem.defectWorkflow.action.a6")&&(OemShared == "true"))

  {
returnResult = true;
  }
console.log("returnResult is " + returnResult);       
  return returnResult;
}
});
})();
==== ==========******************************************************========================
Under "team Configuration" ==> "Operation Behavior" ==> "Save Work Item (server)" ==> "Required Attributes For Condition"
chkoembase_action (condition) is mapped to "OEMshared" required attribute (please make sure this field is not "Read Only", otherwise this will not become "mandatory" (red *) though the condition is met)

This script will make the "OEMshared" field as "mandatory" if the defect is moved from "New" ==> "Reject" directly if the "Oem shared" == "true".

Since I marked "true" as "Unassigned literal" value, when the user click on "Save" button in the above case, system won't allow them to save.

Now I have to work on "customizing" the "message" that is being displayed for the above condition. how to do it?


Your answer


Register or to post your answer.