10 Replies Latest reply on Apr 27, 2006 5:43 AM by Luciano Medina

    Available transitions depending on logged user

    Luciano Medina Newbie

      I am writing a web application that allows the logged user to choose one of some available transitions for a pending task, as in the websale sample.
      There is a task node (TaskAlfa) that will be assigned to two actors A and B by using the setPooledActors method in an AssignmentHandler.
      The problem is that I want the available transitions to be different for each actor. Specifically, actor A should have three possible transitions (t1, t2 and t3) and actor B only one of them (t1).
      How can this be accomplished? I have thought of two possible solutions:

      1. Assign the three transitions to the task node and decide at the webapp bean code, after using TaskInstance.getAvailableTransitions, if we are at the special case (actor B in TaskAlfa), and therefore render command buttons for the three transitions or only for one of them.

      2. Add a fork and create two tasks (TaskAlfa, TaskBeta) instead of one, the first one assigned to actor A with three leaving transitions, the second one assigned to actor B with one transition. When either task is finished, I must find the way to "kill" the waiting token at the other task, so the process instance may continue.

      I find both solutions pretty awkward. Is there a more elegant way to implement what I need?

        • 1. Re: Available transitions depending on logged user
          Andy McCarty Newbie

          wouldn't a decision node work better in place of the fork? That would prevent you from having to "kill" the waiting token.

          • 2. Re: Available transitions depending on logged user
            Andy McCarty Newbie

            sorry, that wouldn't work would it.

            • 3. Re: Available transitions depending on logged user
              Luciano Medina Newbie

              A small correction to the above post:
              In the second solution, I need to "kill" the token at the other task, not for the process instance to continue (it will, cause there is no join node), but in order to eliminate the task instance from the other actor's task list. Otherwise, if actor A finished the task, actor B would still find a pending task, and I don't want that to happen.

              • 4. Re: Available transitions depending on logged user
                Ronald van Kuijk Master

                In one of the very recent other post in a different topic, Alex (the great) reminded me of something. You can put multiple tasks in one task-node and give each task it's own actor. You can then use the signal and end-task attributes to 'configure' the behaviour of the task-node. signal=first and end-task=yes would give the behaviour you need for 'killing the other task' at least.

                The default webapp in 3.1 still renders all transitions afaik. In 3.2 custom forms can be created where you just show the specific transitions.

                This looks like a combination of both, but might be a suitable solution. I at least am going to try and implement something like this for a small internal demo.

                • 5. Re: Available transitions depending on logged user
                  Luciano Medina Newbie

                  Thanks for the reply.
                  I see what you mean, but for what I need, multiple tasks in a task-node are not too different from one task for pooled actors (my first suggestion). The available transitions are per task-node, not per task, so I still have to decide which transitions are forbidden for the logged actor.
                  The ideal scenario would be having transitions per task, but I don't know if that goes against the basis of workflow philosophy (which I am starting to grasp) :-)

                  • 6. Re: Available transitions depending on logged user
                    Ronald van Kuijk Master

                    There IS a big difference. It is possible to have a task node cancel other tasks if one is acted upon. Multiple tasknodes each with their own task cannot do this. You have to write additional code for that.

                    • 7. Re: Available transitions depending on logged user
                      Luciano Medina Newbie

                      No, I mean one task node with multiple tasks vs. one task node with one task assigned to multiple (pooled) actors.

                      • 8. Re: Available transitions depending on logged user
                        Sebastian Oliver Newbie

                        What about an NODE-LEAVE action that evaluates who's logged in and depending on that manipulate the transitions (like for example. storing in some list the available transitions for that user)

                        • 9. Re: Available transitions depending on logged user
                          Ronald van Kuijk Master

                          hmmm... then I don't understand your problem correctly (I think)

                          Let me summarize:
                          - one task per tasknode and a fork
                          advantage: you can have a generic page which shows only the transitions for that task(node).
                          disadvantage: write code to cancel other task

                          - two tasks per tasknode and no fork
                          advantage: other task is cancelled if one of them is acted upon (no code)
                          disadvantage: create custom page per task

                          I'd go for the latter and imo there is more than a little difference. A custom page will be very easy with jBPM 3.2 (one copy action and one delete (of one of the transition buttons) You could even make one page with a dynamically visual buttons for taking the transitions.

                          Cavalera: the node leave is to late in the handling of the action. One is already selected then, so all you can do is throw an 'not-allowed' exception e.g. and handle that in the page. Not an elegant solution.

                          • 10. Re: Available transitions depending on logged user
                            Luciano Medina Newbie

                            Ok, Ronald, there's some confussion here so I will summarize too.

                            1) My first suggestion: one task node, one task, pooled actors, no fork.
                            2) My second suggestion: one fork, two task nodes, one task each task-node.
                            3) Your (Alex's) suggestion: one task-node, two tasks, no fork.

                            I said there is little difference between 1) and 3).
                            You said there is big difference between 2) and 3)
                            I think we're both right, it's just that we were comparing different options :-)
                            You correctly pointed out the advantages and disadvantages of 2) vs 3). I say the same advantages and disadvantages of 3) apply to 1).

                            What I see is that either for 1) or 3), as both have only one task-node and therefore a common set of transitions, it is impossible to define at the processdefinition.xml which transitions are allowed to which actors, no matter if the task-node has one task or multiple tasks .
                            So If I choose 1) or 3), I have to decide at the webapp level, without any help from jBPM, if I have to render a button for this transition for that actor. It's sad that this kind of information could not be available from the processdefinition.xml through the jBPM API, but again, maybe I'm missing the point. I don't know if jBPM 3.2 will help me either.
                            With this in mind, now I find it easier to implement the 2) option (a fork, and killing the other task).