Summary
I'd like to be able to set the current workflow step via the API. Either as a "virtual field" on the related entity, or through a separate API call.
Example
We're migrating a legacy manufacturing workflow management tool to OroCRM. Eventually OroCRM will replace the legacy system entirely, but until it does need to run the two in parallel. We've written a piece of "connector" software that polls the legacy database for changes, and uses Oro's REST API to maintain equivalent entities in Oro's database.
Their existing system has a multi-step workflow for job processing which we've replicated in Oro with a custom Job entity, and a custom workflow using Oro's workflow tools. Users are only able to move between defined steps. e.g. A job needs to be "Entered", then "Approved", and "Scheduled" before it can be "Produced". However, the transition between some steps might be very quick. We're polling the database every half an hour, but the operator might enter and approve a job in a single half hour interval. Likewise, an existing job could be approved and scheduled in the same half hour interval.
This means when a job is created in Oro via the API it may need to be moved into a workflow step other than the default start step. Updates to existing entities via the API may need to transition the entity to a step that wouldn't normally be allowed.
What I'd like to be able to do is either directly or indirectly affect the entity's workflow step via the API. My entity has a "jobStatus" field, it would be great if changes to that field could be mirrored into the workflow steps (as there's a 1:1 correspondence between status and workflow). Oro comes close to making this possible now, see note below. Another option might be to expose "workflow_step" as a virtual field in the API, much the same way as it's inserted as a column into the datagrids. Or alternatively, expose a separate API for workflow items and allow that API to be used to transition an entity to any step.
Note: The existing triggers functionality on the workflow comes very close to enabling the mirroring of the status field. I can define a trigger on each transition that responds to changes in my status field and triggers the workflow transition. BUT, the transition won't be allowed if the user wasn't allowed to make that transition in the UI. Which is a problem when I need to "skip" steps via the API. I can't just enable all transitions on all steps, because then the user can skip steps in the UI, which we can't allow. The simplest way might be to have allowed_transitions_api as well as allowed_transitions in the step configuration. If allowed_transitions_api is used it replaces allowed_transitions for API requests. This would allow me to easily enable all transitions from all API requests.
Summary
I'd like to be able to set the current workflow step via the API. Either as a "virtual field" on the related entity, or through a separate API call.
Example
We're migrating a legacy manufacturing workflow management tool to OroCRM. Eventually OroCRM will replace the legacy system entirely, but until it does need to run the two in parallel. We've written a piece of "connector" software that polls the legacy database for changes, and uses Oro's REST API to maintain equivalent entities in Oro's database.
Their existing system has a multi-step workflow for job processing which we've replicated in Oro with a custom Job entity, and a custom workflow using Oro's workflow tools. Users are only able to move between defined steps. e.g. A job needs to be "Entered", then "Approved", and "Scheduled" before it can be "Produced". However, the transition between some steps might be very quick. We're polling the database every half an hour, but the operator might enter and approve a job in a single half hour interval. Likewise, an existing job could be approved and scheduled in the same half hour interval.
This means when a job is created in Oro via the API it may need to be moved into a workflow step other than the default start step. Updates to existing entities via the API may need to transition the entity to a step that wouldn't normally be allowed.
What I'd like to be able to do is either directly or indirectly affect the entity's workflow step via the API. My entity has a "jobStatus" field, it would be great if changes to that field could be mirrored into the workflow steps (as there's a 1:1 correspondence between status and workflow). Oro comes close to making this possible now, see note below. Another option might be to expose "workflow_step" as a virtual field in the API, much the same way as it's inserted as a column into the datagrids. Or alternatively, expose a separate API for workflow items and allow that API to be used to transition an entity to any step.
Note: The existing triggers functionality on the workflow comes very close to enabling the mirroring of the status field. I can define a trigger on each transition that responds to changes in my status field and triggers the workflow transition. BUT, the transition won't be allowed if the user wasn't allowed to make that transition in the UI. Which is a problem when I need to "skip" steps via the API. I can't just enable all transitions on all steps, because then the user can skip steps in the UI, which we can't allow. The simplest way might be to have
allowed_transitions_apias well asallowed_transitionsin the step configuration. Ifallowed_transitions_apiis used it replacesallowed_transitionsfor API requests. This would allow me to easily enable all transitions from all API requests.