Deny state change depending on user group

  • 8
  • 47

Hello!
How can i make a state machine to deny certain grps of users to change the tasks states to verified?
Ty =)
Hello Josh,

if you need the full-featured state machine then just add the 'assertion' in the 'on enter' statement:
statemachine sm for field State { 
 
  initial state Submitted { 
    on open[always] do {<define statements>} transit to Open 
  } 
    
  state Open { 
    on fix[always] do {<define statements>} transit to Fixed 
  } 
    
  state Fixed { 
    on verify[always] do {<define statements>} transit to Verified 
  } 
    
  state Verified { 
    enter { 
      assert loggedInUser.isInGroup("New Users"): "Cannot change state to 'Verified.'"; 
    } 
  } 
 
}

But also you can just add the simple stateless rule:
rule verified 
 
when State.becomes({Verified}) { 
  assert loggedInUser.isInGroup("New Users"): "Cannot change state to 'Verified.'"; 
}

Oh, thanks alot again!
If i would be allowed to ask: which language does the WFE use, and what can be found to read as a reference, except of the to know it a bit better? =O Except http://confluence.jetbrains.com/display/YTD4/Workflow+Language+Reference
ofc =O

Hi Josh,

I'm working on the rich reference about the workflow language.

If I wanted to assert the loggedInUser was the project leader how would I do this? I am trying to use:

state Closed { 
  enter { 
    if (State.oldValue == {Reopened}) { 
      assert loggedInUser == issue.project.leader: "Only the Project Leader can Close issues that have been Reopened"; 
    } 
  } 
    
  on Reopen[always] do {<define statements>} transit to Reopened 
}


but I am getting an error:

Can't access committed saved entity. Only getId is permitted. Issue: id = 75-23[up-to-date] (Saved)

Hi Darren,

thanks for the interesting case. It looks like the bug, I've created the JT-19483.

You can refactor your code in such a manner, it must help:
state Reopened { 
  on fix[always] do { 
    assert loggedInUser == project.leader: "Only the Project Leader can Close issues that have been Reopen"; 
  } transit to Fixed 
} 
state Fixed { 
  on reopen[always] do {<define statements>} transit to Reopened 
}

Thanks Dmitry, this worked great. I understand this is a bug, but I am curious as to if there is a given reason why I would write assertions in the do block as you have done versus inside of the state enter as I was trying to do?

The 'enter' block is executed on transition into this state from any other state but to control the source state on current transition you have to write the assertion in a concrete event.

Hi Darren,
Let me add my two cents here. It's generally incorrect to check state inside an SM rule or a guard. In case you whan different behavior depending on a source state, you'd better extend your SM to have more states.