How to migrate an automation task so users can set it up from the user interface?

The parameters of the automation tasks can be configured as a dictionary, or parameters with type can be used. The advantage of typed parameters is that they allow the user to choose or enter specific values, making it easier to set up automation tasks or minimize data entry errors.

To begin with, there is an automation task code sample called helloworld (athentose/custom/operations/helloworld.py) that contains examples of the parameters. Before reading on, examine the contents of that file.

Here is an example of parameters:

The key of this dictionary is the name of the parameter that we can use to obtain its value.

The fields to be filled in are:

• label: Label that the parameter is going to have in the automation tasks.
• help_text: User help text.
• type: Indicates the type of object that the parameter will return.
• subtype (optional): If the parameter is CHOICE, it indicates the type of elections that will be presented to the user. In this example, users are presented.
• is_multiple (optional): Indicates if several values can be chosen.

For the type field the available options are:

TEXT: the parameter is a string.
INTEGER: the parameter is an integer.
FLOAT: the parameter is a number with decimals.
EVALUABLE: the parameter is a text string that is evaluated as Python code.
BOOLEAN: parameter is a Boolean value (on/off).
DATE: parameter is a date.
DATETIME: the parameter is a date and time.
CHOICE: the parameter presents a series of options to choose from depending on 
the subtype.

The available values for the subtype option are:

CUSTOM: allows you to define the available options within the parameter.
METADATA_TYPE: allows you to choose among the available field types.
USER: allows you to choose among the available users.
DOCUMENT_TYPE: allows you to choose among the available forms.

In the case of working with CHOICE type and CUSTOM as subtype, custom values can be defined by adding a "choices" key to the configuration of this parameter, as in this example:

'my-custom-choice-key': {
    'label': 'Custom choice parameter',
    'help_text': 'My custom choice parameter',
    'choices': [{"label": "Custom label A", "value": "value_a"},
                {"label": "Custom label B", "value": "value_b"}],
    'type': ProcessOperationParameterType.CHOICE.value[0],
    'subtype': ProcessOperationParameterChoiceType.CUSTOM.value[0],
    'is_multiple': False,
}

Being "label" the label shown in the configuration interface for the user and "value" the internal value to be used by the operation.

Use params.get('my-user-parameter-key') to obtain the value of a particular parameter.  The returned value will depend on the type of the parameter (for the example, it returns an object of the User class).

There is no automatic method to change old parameters of the automation tasks to use this type of parameter since each automation task uses the parameters in a different way.

Roughly speaking, the steps to follow are (I take the op_start_lifecycle operation as an example):

PARAMS = {'life_cycle_name': '', 'parallel':''}

1. Study the automation task code, its aim, and procedure.
   In this particular example, we see that 'life_cycle_name' is the name of a lifecycle, and 'parallel' is used as a boolean.
   Write the parameters in a variable called CONFIGURATION_PARAMETERS.

2. CONFIGURATION_PARAMETERS = {
       'life_cycle_name': {
           'label': 'Lifecycle Name',
           'help_text': 'Name of the lifecycle',
           'type': ProcessOperationParameterType.TEXT.value[0],
       },
       'parallel': {
           'label': 'Parallel',
           'help_text': 'Select to indicate if the life cycle is parallel',
           'type': ProcessOperationParameterType.BOOLEAN.value[0],
       }, 
   }

3. Use params.get() when you need it and test the overall behavior of the code.

Finally, it is possible that some automation tasks that are previously installed on a server don't display the parameters properly. 

The following command has been created that goes through each installed and configured automation task, and tries to transform the PARAMS in dictionary form to configurable parameters. After executing it, it is advisable to check that the parameters created are correct since it is not always possible to deduce the type properly:

python manage.py migrate_operation_parameters