Conditional transition depending on actor and variable

1
0
-1

Hi,
I'm developing an application which invokes bonita's REST API and I'm currently at the process workflow design stage.

I need to implement the following scenario:

From an initial state - let's say "open"- there are 3 different transitions available, let's say: "paused", "cancelled", and "closed". What I would like to obtain is that:

  • from the "open" state, after a transition the case moves only to one of the children state (i.e. is not forked or splitted)

  • anyone can move the case to the "closed" state, but only a specific actor (let's say a special user) can move it to "canceled or paused"

How can I design this behavior?

2 answers

1
0
-1
  • reported as a commento to Sean's answer*

Comments

Submitted by Sean McP on Wed, 03/09/2016 - 16:23

OK...no problem with 1)

and you're really only changing a variable aren't you? You're not doing anything else...

So don't use the REST just submit the formOutput variable to the value you want on clicking the submit button. Yes you can have more than one...

So set up paused / cancelled / closed buttons each as Submit button with their individual returns.

Then populate the case BDO using setStatus and end...no need to use REST. All users will now see the new status of this case.

regarding 2.3 this will not be possible using the Submit button, the API call is hidden so it will never be visible, and as you've already show or hide frontend-side the buttons they will never see it...

regards
Seán

Submitted by marcogagliardi84 on Wed, 03/09/2016 - 16:27

I need to use REST since I'm building my own frontend application not bonita's UI.
It's a full HTML/Js application which interfaces with bonita's bpm engine through REST requests

Submitted by Sean McP on Wed, 03/09/2016 - 17:53

:)

You know that would have helped in the beginning... :)

I'll be back...

1
0
-1

When in Open state have a dropdown selection list that allows the 2 1/2 states in it, closed, canceled and paused.

When the user is in the form they must choose one of the 2 1/2 states...the process will then only follow one of three paths in the process, it cannot be forked, or split. You do this through a gateway. This solves 1)

Now on to 2). And you are probably still wondering why I say 2 1/2 states...bit of programming humor.

You have two sets of people and three states but only one set can use all three, the other uses two.

In the process before showing the form for 1) build the dropdown selection list and pass it to the form. When you are building it you can use a groovy connector to determine what the actors role is user or super user and then only populate the values you need.

For a user you use only canceled and paused and for a super user use all three.

So the DDL is 2 choices or 3 choices (added = 5) / number of roles (2) = 2 1/2... :)

Silly I know, but hey, what else have I got to do...

regards
Seán

PS: If this reply answers your question, please mark a resolved

Comments

Submitted by marcogagliardi84 on Wed, 03/09/2016 - 16:22

Thank you Seán.

Actually for the moment I don't need to use a groovy connector to populate the option list depending on the user: I will show or hide frontend-side the buttons to trigger a task (Pause / Cancel / Close) after evaluating the user info ( role and/or group_id).

What I need to clarify is :
- how to design the possibility to transit from one state to only one of 3 children states. This means that after such transition, if the case for example has moved to paused state, all users will see this case marked as paused. (a gateway will be enough?)
- how to implement such transition via Rest API and tell the system which state the case should be moved to
...maybe invoking:

/API/bpm/humanTask/[idActivity] 

and passing the parameter "state": "paused / cancelled / closed" ?
- (appreciated) how to configure bonita to return an error if a normal user invokes the API to move a case to a protected state

Thank you

Notifications