you could write an action that throws an exception in case the condition evaluates to false.
but we have been reluctant in adding support for this because we think these non-allowed operations should never be offered in the user interface. such a 'guard' action could only throw an exception, when a user activates a command in the UI and gets the message "you're not allowed to do this". then why offer the command in the UI in the first place ???
or can you state a use case where a guard is necessary ?
The action should be activated on a 'node leave' event, right?
I agree that these non valid actions shouldn?t be offered in the UI, however since I?m using a WF based solution I would like the WF to be my safety net regarding process execution and not the UI, but it's just my opinion.
Thanks for your quick answer.
But the ui is also responsible for displaying forms etc... what Tom means is that you should e.g. adapt the ui and have a process variable contain e.g. a true or false (or any other 'precondition') whether the transition should be displayed or not. The ui is not 'responsible' then.
I was thinking of defining a custom TaskInstance and adding a boolean field such as "isInteractive" to determine if the UI should allow the user to alter the task (or any node for that matter). What are the thoughts on such an approach? If it were to be done would there be any way to configure this as true or false in the process definition file?