...
We need to provide a generic way to handle changes in entities. Workflows Tasks should be accessible from one place on UI and created with signals on backend site of application.
All modules should be able to make contributions to 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 what users can work on certain tasks.
Task Executor is person responsible for finishing the task.
...
They’re defined as group of users.
Proposed flow of tasks (for data update in coreMIS beneficiary):
...
:
...
Expand | ||
---|---|---|
| ||
@startuml boundary DataSource as D TT -> TG : Create Task Group |
In this scenario Tasks are defined on backend and triggered on 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 user can check theirs tasks and complete
...
BusinessActions on them
...
. Search criteria are used to filter on standard task fields (mentioned later on 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 user can check theirs 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 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 user to check how task affects the state. In case of beneficiaryupdate it could display modal explaining what changes will be applied.
Approve/Reject businessStatus allows user to either complete or fail take proper action on 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.
Possible approach for this field is different for different task groups. It could be for instance Approve/Reject changes in update request, or set new amount for policy adjustment request. It could be a 3 dot menu, dropdown, or text inputs.
Assignee is group of users that are authorized for completing the task. Task executioner groups should have assigned approval policies which determine when given task is considered finished by the group. It could be: at least one approval, approval threshold, all members approval
...
Received - when new tasks appears 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 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.
If given user is a Triage but not Executor of a task, BusinessStatus is blocked.
If give user is a Executor but not Triage of a task then Assignee is blocked.
Entities
...
Expand | ||
---|---|---|
| ||
@startuml object Task object TaskGroup object TaskExecutionerRevolve @enduml |
Stories
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.
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).
Story 3 - Task Assignment: As a Task Administrator Triage I want to assign specific tasks to previously defined user groups.
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.
Story 3 - Task Execution: As a task 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.
Story 4 - Task Completion: As a task executor, when I finish a task, I want to update its status so that the system can determine the next steps in the workflow.
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.
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.
...
The user performs certain action in the system.
The event attached to this action is triggered
TaskReceiver binded to the event gets new action
New Task object is created with status RECEIVED
Task is saved in storage
New Task appears under “My Tasks” view for certain Task Administrators Triages
Extensions:
N/A
Postconditions:
The task is created.
Task Admin Triage can assign task to group.
Use Case 2 - Task Assignment:
Actor: Task Admin Triage (User)
Trigger: New task was added to the system
Preconditions:
Task Admin Triage has access to manage certain task
Main Flow:
Task Admin Triage goes to the “Tasks” view
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.
Status of the task changes to ACCEPTED
...
Alternative Flow - Task Rejected :
Task Admin Triage goes to the “Tasks” view
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:
Task Administrator Triage has access to create Task Executioner Groups
Main Flow:
Task Administrator Triage goes to Users → Task Executioner Groups (added as extension)
Task Administrator Triage select users that will be in scope of the Group
Task Administrator Triage select GroupPolicy from dropdown
New Task Group is created
...
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?
...