Workflows

Tausi’s workflows model the business process Kenya Law follows to ingest, markup and publish a decision. A decision is almost always modified or created only as part of a workflow process.

Tausi uses Viewflow to model and process the workflows. Viewflow is a rich, mature, flexible workflow library for Django.

Separation of concerns

Workflow models, views, templates etc. form part of the tausi_workflows Django app.

It is important that workflow-related business logic is kept to tausi_workflows, and decision-related (and workflow-independent) business logic is kept to tausi. This makes it easier to adjust and introduce new workflows without disrupting the underlying main decision business logic.

+---------------------------------------+
|               Workflow                |
+---------------------------------------+
+-----------+ +-----------+ +-----------+
|   Task    | |   Task    | |   Task    |
+-----|-----+ +-----|-----+ +-----|-----+
      |             |             |      
      |    +--------|--------+    |      
      +----+    Decision     +----+      
           +-----------------+           

Audit trail

Workflow events contribute to a decision’s audit trail. For example, when a workflow is completed or a task is assigned to a user, that event is recorded in the associated decision’s audit trail.

Tasks

Workflows are made up of tasks. Most tasks require human interaction, although some tasks may be automated.

Tasks that require human interaction require views (web pages and forms) that are tailored for that task. For example, the task view for writing a decision summary doesn’t include fields that allow the user to change the dates of a decision. This makes it easier for the user to perform the task and reduces the likelihood of accidental errors.

Tasks are automatically assigned to a user. This is determined from the permissions required by the task and the roles (groups) in the system.

Reviews

Most tasks require a review stage before the workflow can continue. This allows a different user to review the work done previously, and either request changes or approve it. Requesting changes moves the workflow back to the previous task (and re-assigns the task), and approving the task moves the workflow to the next task stage.

The view used for the review of a task is normally the same as the view for performing the task (except that the task activity buttons change). This means the two users understand what the other is seeing, and the reviewer can, if necessary, make their own changes.

Published vs unpublished

While a decision is being marked up and reviewed, it is not visible to the public, it is unpublished. Once a decision has been reviewed and signed off, it is marked as published and is available to the public through the API.

Implementation

Task views

Task views are normal Django views, with some additional logic to handle the task process. This additional logic ensures the user is allowed to execute the task and has been assigned to the task.

Tasks that involve updating a decision use Django’s UpdateView.

Review tasks that require approval to proceed extend the view for the task being reviewed, and have an additional field that indicates whether or not the submitting user approves the task.