Design Doc for Task Unassignment

Overview

Currently there is no way to un assign a task. To un assign a task the super user needs to assign the task to self and then it reflects it in overdue for them.

Goals

The primary objective is to implement a feature that allows for the unassignment of tasks within the system. The goal is to streamline this process by providing a straightforward method for super users to unassign tasks without the need for assigning it to themselves as a workaround.

Steps for Task Unassignment

1. Locate Task on Status Site:

• Super users navigate to the status site and locate the specific task they want to unassign.

2. Task Card Interface:

• On the task card of the selected task, the super user, being the only authorized entity, can exclusively access and click the Unassign button.

3. Initiate Unassignment Process:

• The system processes the unassignment request and removes current assignee from the task.

4. Queue Update:

• After successful unassignment, the task is returned to the pool of unassigned tasks.

5. Visibility on Status Site:

• The task now appears under the Unassigned tab on the status site, indicating its availability for reassignment.

Testing

• Every modification made to the frontend components on the status site and backend functionalities within the website backend will undergo comprehensive unit and integration testing.
• The initial phase of testing will occur in a staging environment, conducted discreetly behind a designated feature flag. This ensures that potential issues are identified and resolved before the changes are exposed to the broader user base.
• Only after successful testing in the staging environment and verification that the modifications perform as anticipated will the changes proceed to the production environment for further validation.

Roll out strategy

1. API Update:

• Initiate the task by updating the backend API. This allows for the implementation of new functionalities in the /task route.

2. Feature Flag Implementation:

• Introduce a feature flag to encapsulate the change. This enables a controlled rollout, as the new features will remain hidden from users initially.

3. Backend Testing (Staging):

• Conduct thorough testing of the updated backend functionalities in a staging environment. This testing phase ensures that the backend changes function as intended and are free from bugs.

4. Backend Testing (Production):

• Gradually roll out the updated backend functionalities to a limited audience in the production environment, still concealed behind the feature flag. Monitor system behavior and address any unexpected issues that may arise.

5. Frontend Update:

• Once the backend changes are successfully deployed and verified, proceed to update the frontend components on the status site.

6. Frontend Testing (Staging):

• Conduct comprehensive testing of the updated frontend features in the staging environment to ensure seamless integration with the backend changes.

7. Frontend Testing (Production):

• Gradually release the updated frontend to a limited audience in the production environment, while still keeping it behind the feature flag. Monitor user interactions and gather feedback.

8. Full Rollout:

• If both backend and frontend changes prove to be stable and perform as expected, proceed with a full rollout by removing the feature flag. This makes the new features accessible without the feature flag.

Roll back strategy

Since the task unassignment feature is deployed behind a feature flag, any potential issues or major disruptions will not impact production users. In the event of critical or breaking changes, a pull request will be promptly raised to revert the changes, ensuring a swift return to the previous stable state.