does programmatically setting workitem state use role permissioning?
I have a custom work item that programmatically goes from state to state. I'd like to configure and prevent users of the system from being able to choose actions and going from one state to another.
Programmatically, if the state is changed on the server through setting the WI action through an operational follow-up action, does it check the role based permissions? If so, is there a standard role the programming API uses?
I'm trying to understand how it could work, so any guidance is appreciated..
3 answers
As Sam explains there is always a user. In your case however, the user that would be used in the Participant is the user that triggered the operation. So the user would have to have the right to do so and I can't see how to make this work in a Participant. A different approach would be to run a client or server job that uses a different user and does the state change in a different context. In this case it would be possible to prevent the normal users from changing the state while allowing the automation user to do so.
