Transitions... How Does It Know?

[lucille_arkenst]

In the case where a task node has two leaving transitions—one for approve and one for reject—how does it know which transition to take? Is this something you get for "free" when the user interface fires off approve or reject? And then it maps itself to the name of the transition or something?

I read a definition that said: "The default transition is the first transition in the list".  But if this were true, then the parallelreview_processdefinition.xml would go straight to the end because the transition always goes to "reject"/"rejected" first.

Does anybody know how it works?

[sethatrothbury]

Hey Lucille, you moved your post on me as I was writing my reply in the other thread… Here's a simple explanation of the thought process behind the parallel review process definition:

In the processdefinition you'll notice that there are both nodes and task-nodes. A task node means that it will require some sort of interaction from the user, meaning that the transitions that are applied to it will become buttons in the Alfresco UI. So, where the startreview node moves directly along its transition to the review task-node, the task-node will wait for a user to click "Approve" or "Reject" in the UI.

Jboss's definition is correct. If you click the Approve button, it is in fact "true". In the startreview node, there is only one transition, so obviously it will follow it. Let's look at the "isapproved" decision node though. There are two transitions that can be followed and , as a decision node, no user interaction to choose which path to take. The code will test each transitions condition clause to see if it is true, the first condition that it finds that is true, it will follow. If none of the conditions equate to true, it will look at what transition is declared first and follow that transition(in this case, the reject transition).

[lucille_arkenst]

Hi!  Sorry… I was marking that one as "solved", I figured this is a whole new topic…
How do you know what you know?  I remember you saying you've read a lot of things… but I have as well.  I've got two Alfresco books, and I have read a bunch of online articles, and everything just kind of comes up short.  It is very kind of you to respond to my posts, and you have been very helpful.  I appreciate that, and I want to be polite and not take up your whole day.   Do you remember what in particular you've read so that I could read it and answer for myself these questions that I'm asking?

Also, let's say the user clicks "approve".  But the percentage doesn't match the requirements.  So both "reject" will be false and "approve" will end up being false.  Then… where does execution end up?

        <transition name="reject" to="rejected" />
        <transition name="approve" to="approved">
            <condition>#{wf_actualPercent >= wf_requiredApprovePercent}</condition>
        </transition>
‍‍‍‍‍

[hsohaib]

Also, let's say the user clicks "approve".  But the percentage doesn't match the requirements.  So both "reject" will be false and "approve" will end up being false.  Then… where does execution end up?

        <transition name="reject" to="rejected" />
        <transition name="approve" to="approved">
            <condition>#{wf_actualPercent >= wf_requiredApprovePercent}</condition>
        </transition>
‍‍‍‍‍

these transitions you mentionned belongs to a "decision node" not a "task node", it doesn't requirer user interaction, if the condition is met the transition "approve" is signaled, otherwise the transition "reject" is signaled.
So in the example you stated, the user click "approve" = transition "approve" of the tasknode "review" is signaled, the workflow progress and is now at the "decision node" , the percentage doesn't match the requirements = transition "reject" of the "decision node" is signaled.

[sethatrothbury]

What hsohaib said is correct. The "reject" transition in the decision node is already true, as it has no condition clause. The only reason it isn't followed immediately is because the workflow will check to see if there is a transition with a condition clause that evaluates to true first. If it doesn't find one, it will default to the "reject" transition as the only true transition.

[lucille_arkenst]

Really!  Hey that makes sense now.  I am doing a test using parallelreview_processdefinition.xml.  And I don't understand how to send emails to members of a swimlane.  Could you please have a look and possibly tell me what's wrong with it and why?  Thanks…

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.1" name="wf:parallelreview">

  <swimlane name="initiator" />

  <swimlane name="group01">
    <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
      <pooledactors>#{people.getGroup('GROUP_group01')}</pooledactors>
    </assignment>
  </swimlane>
  
  <start-state name="start">
    <task name="wf:submitParallelReviewTask" swimlane="initiator" />
    <transition name="" to="startreview" >
      <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
        <script>var all_members = people.getMembers(group01);
          
          for(var i=0; i &lt; all_members.length; i++ )
          {
          var mail =  actions.create("mail");
          mail.parameters.to = all_members[i].properties.email;
          mail.parameters.subject = "New document is waiting";
          mail.parameters.from = "admin@alfresco.com";
          mail.parameters.text = "Some text";
          mail.execute(bpm_package);
          }</script>
      </action>
    </transition>
  </start-state>
  
 …

</process-definition>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[hsohaib]

You have an error in this line :

var all_members = people.getMembers(group01);
‍‍‍

the var group01 is undefined, it should work if you replace it with   :

var all_members = people.getGroup('GROUP_group01').getMembers();
‍‍‍

[lucille_arkenst]

OK, thanks.  So you call it "group01" and then people.getGroup knows that a prefix "GROUP_" signals that a group name is to follow, right?  Once you assign that swimlane to a task, is that all that needs to be done?  Or do you also need to do something with #{bpm_assignees}?

[nhutminh87]

Thank all