Deny state change depending on user group

Hello!
How can i make a state machine to deny certain grps of users to change the tasks states to verified?
Ty =)
8 comments
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.'"; 
    } 
  } 
 
}
prettyPrint();
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.'"; 
}
prettyPrint();
0
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
0
Hi Josh,

I'm working on the rich reference about the workflow language.
0
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 
}
prettyPrint();

but I am getting an error:

Can't access committed saved entity. Only getId is permitted. Issue: id = 75-23[up-to-date] (Saved)
0
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 
}
prettyPrint();
0
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?
0
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.
0
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.
0

Please sign in to leave a comment.