ModelOp-Managed Approvals

Allows the ability to create ModelOp-managed approvals of different subtypes, each with configurable titles, resolution states, and comment tracking

Configuration

The SCCS Key for the task management is (key used in gateway service)

center.tasks.configuration

The configuration is made up of two key properties:

types
actions

Each type has the following properties:

id: String ID. This will be set as the notification subtype.
label: Human readable text
states: A collection of states for the task type
  state:
    status: Human readable ticket status
    open: Boolean that indicates if the ticket is open
    actions: A string array referencing actions from the actions array in the config

Each action has the following properties:

id: String ID of the action
label: Human readable string name of the action
changes: The changes being made to the task entity when the action is performed
  close: Whether to close the ticket
  status: The status to change the ticket to. Should reference the status in the states section

Example use

In the following screens we can focus on the request for validation subtype defined in the full example above.

When the above has been configured in the gateway property specified above, the Use Cases should now show an extra button “Create Task” as shown below.

When you click on the button, a screen as below will appear where you can populate the “summary”, “type”, “Priority” and “Due Date”. Note that the Task notification will be linked to the given Use Case.

Also note, the options for “Type” are going to be shown as specified in the JSON configuration mentioned above.

As the Task is submitted (created), it will be displayed in the Use Case. Please note the actions shown by clicking in the “three-dots” button as shown below, will match what the configuration specified, In this case, valid actions are: “Send Back” and “Approve” as it is currently in “Open” state. You can always “Edit” and “View Details”

This will create a very simple, yet powerful mechanism to deal with custom approval and actions.

Notification Additional Input

It is possible to provide specific additional input depending on the notification subtype (like “Request Validation” from the example above), by linking an application form to the Notification object.

This can be automatically achieved by using an MLC and a DMN as explained below.

First we need to create an Application with the desired data collection points for specific Notification subtype. We need to capture the application form UUID, as seen on the address bar.
Using the application form IDs, we should create a DMN using the Camunda Modeler, to match the desired notification subtypes with the application form ids.
Next, we should deploy both the DMN above, and the MLC provided as attachment in this article and shown here.
Finally, when we create a notification of such subtype, the MLC will catch its creation and associate the Application Form ID which will cause it to show as the screen below in the “Additional Input” section.