An activation filter can be configured on a workflow definition. However this filter is only used by the runnableWorkflow API enricher in order to display/hide the worflow in webui.
Using the REST API, any authenticated user can start any workflow on a document as long as it has READ permission. This is seen as a defect and a potential issue by some cutomers and SIs
- add a method canCreateInstance to the DocumentRoutingService service. This method will use the input documents, session and workflow name, evaluate the filter configuerd in the workflow definition and return a boolean
- this method will be called by the API WorkflowAdaper, WorkflowObject and the StartWorkflow automation operation class
- the control is not embedded in the createNewInstance method of the service and the responsability of checking that a workflow can be started is left to the caller. This is to avoid having something too strict which doesn't allow exceptions
Additionaly, the logic in RunnableWorkflowJsonEnricher to get the list of workflows that are runnable by a user on a document could be completely moved to a new method in DocumentRoutingService in order to make it more reusable.
Alternative solution suggested by alain, instead of adding a new canCreateInstance method to the service, create a new extension point and an interface to leave the possibilty so the default implementation can easily be overriden.