Deny state change depending on user group

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

Votes

0

Share

8 comments
Avatar
Dmitry Krasilschikov
Created
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.'"; 
}
0
Avatar
GH
Created
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
Avatar
Dmitry Krasilschikov
Created
Hi Josh,

I'm working on the rich reference about the workflow language.
0
Avatar
darren.cunningham
Created
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)
0
Avatar
Dmitry Krasilschikov
Created
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 
}
0
Avatar
darren.cunningham
Created
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
Avatar
Dmitry Krasilschikov
Created
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
Avatar
Alexander Volfman
Created
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.