Versions Compared

Old Version 1

changes.mady.by.user Damian Borowiecki

Saved on

compared with

New Version Current

changes.mady.by.user Jan Dołkowski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Proposed The proposed solution is based on Patrick’s approach for workflows Workflow: Task based update of entities.

We need to provide a generic way to handle changes in entities. Workflows Tasks should be automatically created through signals by the application backend and accessible from one place and created with signals on backend site of application. on the UI. All modules should be able to make contributions to the main Tasks Page.

There will be 2 types of users Users interacting with the tasks: Administrator and Executor. Task Administrator

  • Task Triage is responsible for managing

...

  • the users that can work on certain tasks. It is an actual role with the right authorities.

  • Task Executor is the person responsible for

...

  • executing the task.

...

  • They’re defined as a group of users called Task Group.

Proposed flow of tasks (for data update in coreMIS beneficiary):

...

In this scenario Tasks are defined on backend and triggered on :

...

Expand
titlePlantUML

@startuml

boundary DataSource as D
actor TaskTriage as TT
participant TaskGroup as TG
note left TG
ideally task
groups are Django groups
end note
actor TaskExecutor as TE
control TaskBasedAction as B
entity BenefciaryORM as BO
entity Task as T
queue TackActions as TA
boundary ActionStorage as AG
boundary Action as A

TT -> TG : Create Task Group
TG --> TE : Assign user to group
TG -> TT : Success
D -> B : TriggerAction(event)
B -> T : Create New Task
T -> B : Task Created
B -> D : Success
TT -> T: Assign task to group
TE -> T: Get Task
TE -> TE: Work on task
TE -> T: ResolveTask(businessStatus)
note right
This checks will be resolved by the task event.
end note
T -> TA: Trigger businessEvent(task, user, businessStatus)
TA -> TG : Get group resolve policy
note right
action and storages depends on specific events,
could be changing some data,
approviing update, etc.
for different policies we might have different
actions. sometimes one approval will be enough,
other time we want to store user decision and
act upon it later. It depends on specific task
end note
alt ANY Resolve Policy
TA -> A: PerformOperation(businessStatus)
TA -> T: CompleteTask()
else ALL Resolve Policy
TA -> A: PerformOperation(businessStatus)
TA -> TE: Save information about user completion
opt All users finished task
TA -> T: CompleteTask()
end
else N Resolve Policy
TA -> A: PerformOperation(businessStatus)
TA -> TE: Save information about user completion
opt Enough users finished task
TA -> T: CompleteTask()
end
end
@enduml

In this scenario, Tasks are defined in the backend and triggered by specific actions.

User Interface

We will need two new views for the tasks implementation: one for the administrator and second one for the executor.

Task Executor’s view

Task executor’s view one new view that will handle functionality for both Task Triage and Task Executor.

For Task Executor:

View serves as a point in which

...

users can check

...

their tasks and complete

...

the BusinessActions on them

...

. Search criteria are used to filter on standard task fields (mentioned later

...

in this document).

Source is a module from which given task is coming from (can be SocialProtection, Claims or others).

Type represents type of task that is listed. For instance, it could be BeneficiaryUpdate, BeneficiaryGraduate, ReportReview or BatchExecutionFor Task Triage:

View serves as a point in which users can check their tasks and complete BusinessActions on them. Search criteria are used to filter on standard task fields (mentioned later on in this document).

Source defines an entity Requesting the change.

Type represents what kind of task the user has. Different types of tasks can have other BusinessActions.

Entity informs about what object is being changed (specific individual, beneficiary, etc.)

Preview is an action allowing the user to check how a task affects the state. In the case of beneficiaryupdate a beneficiary update, it could display a modal explaining what changes will be applied.

Approve/Reject allows user to either complete or fail given task. If task is fully completed then proper action is triggered on backend.

...

Task Administrator View

This view shows all existing tasks in the openIMIS application. It is a low level placeholder to which other modules can contribute to. In graphic below Benefit Plan Tasks is a contribution from SocialProtection module. Most of the entities is similar to ones in “My Tasks” view.

Benefit Plan is a specific entity.

Assignee is Assignee is a group of users that are authorized for completing to complete the task. Task executioner groups should have assigned approval policies which that determine when a given task is considered finished by the group. It could be: at least one approval, approval threshold, all members approval.

BusinessStatus allows the user to take proper action on a given task. The possible approach for this field is different for different task groups. It could, for instance, Approve/Reject changes in an update request or set a new amount for a policy adjustment request. It could be a three-dot menu, a dropdown, or text inputs.

Status represents the current state of the task. According to the FHIR standard and our current needs, we should have the following states:

  • Received - when new tasks appears appear in the system

  • Accepted - when task is assigned to the executioner

  • Completed - when changes were approved by executioner

  • Failed - when changes were not approved

...

Entities

...

...

This view shows all existing tasks in the openIMIS application. It is a low level placeholder to which other modules can contribute. In the graphic below, Benefit Plan Tasks is a contribution from SocialProtection module. Most of the entities are similar to those in the “My Tasks” view.

If a given user is a Triage but not an Executor of a task, BusinessStatus is blocked.

If a given user is an Executor but not Triage of a task, then the Assignee is blocked.

Entities

...

Expand
titlePlant UML

@startuml

object Task
Task : id : UUID
Task : dueDate : date
Task : source : str
Task : entity : Genefic FK
Task : status : ENUM(RECEIVED|ACCEPTED|COMPLETED|FAILED)
Task : completeAction : Event
Task : businessStatus: str
Task : businessAction : Event
Task : TaskAdmins : [User]
Task : Data : Any
note left
"Data" is an
input that comes to the trigger
it can be unstructured but has to provide
enough information for the user to take action
(like see changes in preview) and provide event
listeners with information.
end note

object TaskGroup
TaskGroup : id : [UUID]
TaskGroup : code : str
TaskGroup : users : [User]
TaskGroup : tasks : [Task]
TaskGroup : completionPolicy : ENUM(ALL|ANY|N)
note right
we need to check if utilising django
groups is possible
end note

object TaskExecutionerRevolve
TaskExecutionerRevolve : id : UUID
TaskExecutionerRevolve : user : User
TaskExecutionerRevolve : task : Task
TaskExecutionerRevolve : businessStatus : str

@enduml

Stories

  1. Story 1 - Task Creation: As a system, when a certain event is triggered, I want to create a new task so that the corresponding workflow can be started.

  2. Story 2 - Task Management: As a Task Administrator Triage, I want to have access to all tasks I’m eligible to manage (e.g. BenefitPlanTasks).

  3. Story 3 - Task Assignment: As a Task Administrator Triage, I want to assign specific tasks to previously defined user groups.

    1. ALT: As a system, when a new task is created, I want to assign it to a user or group based on predefined rules so that the task can be executed by the appropriate party.

  4. Story 3 - Task Execution: As a task executorTask Executor, I want to see only the relevant information for the entity page and be able to validate information as necessary so that I can complete the task without confusion or errors.

  5. Story 4 - Task Completion: As a task executorTask Executor, when I finish a task, I want to update its status so that the system can determine the next steps in the workflow.

  6. Story 5 - Workflow Progression: As a system, when a task is completed, I want to determine the next steps based on the current workflow implementation and status so that the workflow can progress smoothly.

  7. Story 6 - Group Management: As a Task Administrator Triage, I want to create/update/delete group of task executioners that can be assigned to specific tasks.

...

  1. TaskCreation action is listening to an event.

Main Flow:

  1. The user performs certain action in the system.

  2. The event attached to this action is triggered

  3. TaskReceiver binded to the event gets new action

  4. New Task object is created with status RECEIVED

  5. Task is saved in storage

  6. New Task appears under “My Tasks” view for certain Task Administrators Triages

Extensions:

N/A

Postconditions:

  1. The task is has been created.

  2. Task Admin Triage can assign the task to group.

Use Case 2 - Task Assignment:

Actor: Task Admin Triage (User)

Trigger: New task was added to the system

Preconditions:

  1. Task Admin Triage has access to manage certain tasktasks.

Main Flow:

  1. Task Admin Triage goes to the “Tasks” view

  2. Under specific extension point tasks (like Benefit Plan) Task Admin Triage selects a group of users that will work on given task from the list of groups.

  3. Status of the task changes to ACCEPTED

...

  1. New task is saved in the system.

  2. TaskCreate event is triggered

  3. Based on criteria, the task is assigned to one group

Alternative Flow - Task Rejected :

  1. Task Admin Triage goes to the “Tasks” view

  2. Task Administrator Triage doesn’t approve the task and changes status to REJECTED

...

Use Case 4 - Group Creation:

Actor: Task Administrator Triage (User)

Trigger: N/A

Preconditions:

  1. Task Administrator Triage has access to create Task Executioner Groups

Main Flow:

  1. Task Administrator Triage goes to Users → Task Executioner Groups (added as extension)

  2. Task Administrator Triage select users that will be in scope of the Group

  3. Task Administrator Triage select GroupPolicy from dropdown

  4. New Task Group is created

...

  1. Created group can be assigned to the tasks by the Test Administrator Triage

Extensions:

2a. We might want to add restrictions based on the user roles / rights / locations in terms of creating groups to keep them coherent?

...