Problem
Often there is a need for workflow-step dependant configurations, which is currently not achievable in translate5

Use cases are :

• visualApproval workflow-step, where visual exchange operation shall handle the uploaded file differently than in other steps
• AI Quality Estimation - where model options are handled differently based on the workflow-step

Solution

Introduce workflow-step dependant variants of configurations

• they target any config-value on all levels
• they will only be available for certain configs to not overwhelm the needed management UI
• they will not be part of the normal table-based overwriting stategy and have a seperate API

The model will be like:

LEK_workflow_config_variant (id, name, value, customerId, taskId)

Zf_configuration will be amended with column workflowVariant (0|1) to flag configs being potentially workflow specific

-> system level variants have neither customerId nor taskId set

-> customer level variants have a customerId set

-> task level variants have a taskId set (this may is not needed for the beginning or even needed at all)

-> task-entity & job-entity will have methods to get workflow configs.

The hierarchy of the evaluated configs in the new API is:

workflow-variant "task" > workflow-variant "customer" > workflow-variant "system" > normal config "task" > normal config "customer" > normal config "system"

The APIs should be tailored to retrospectively replace calls to the task-config with a call to a workflow-variant. So instead of

$task->getConfig()->runtimeOptions->xyz 

one calls

$task->getWorkflowStepConfig('runtimeOptions.xyz')

Management UI

• initial rollout can happen without UI
• basically two variants:
• own UI for workflow-config, basically like the normal config showing just those being workflow-specific with a workflow-step dropdown per config
• or as "mode" of the existing config: selecting a workflow-step on top of the existing UI will set the step & filter for the configs having workflow-variants
• both variants will exist on system & customer level just like the "real" config management