This document outlines the web flow for managing checklists within a campaign context, including viewing existing and creating new checklists. The process involves interaction between the user and various backend services to ensure the correct retrieval, creation, and modification of checklists associated with specific campaigns.
User: The individual interacting with the checklist management UI to view, create, and modify checklists.
Checklist View UI (CurrentScreen): This is the user interface for viewing existing checklists and initiating the creation of new ones.
Checklist Create UI (CurrentScreen): The user interface for creating and configuring checklists.
Service Request Service (ServiceRequestService): Manages service requests and updates related to checklists.
MDMS Service (MDMSAPI): Provides master data management services for roles, checklist types, and other configurations.
Localisation Service (LOCAPI): Manages the localization of checklist questions.
Access Checklist View UI
The user accesses the Checklist View UI after a campaign has been created.
Fetching Configured Service Requests
CurrentScreen sends a request to ServiceRequestService to fetch configured service requests.
ServiceRequestService filters and returns checklists using the campaign name, role, and type, or just the campaign name (if the service is enhanced).
ServiceRequestService returns the relevant checklists to CurrentScreen.
Display Checklists
CurrentScreen displays the checklists received from ServiceRequestService to the User.
Creating a New Checklist
The user clicks on "Create Checklist" in the Checklist View UI.
CurrentScreen sends a request to MDMSAPI to fetch role and checklist type master data relevant to the campaign type.
MDMSAPI returns the master data to CurrentScreen.
The user selects the desired role and checklist type.
CurrentScreen redirects to the checklist creation screen based on the selected campaign name, role, and type.
Enable/Disable Checklist
The user clicks on the enable/disable option for any checklist.
CurrentScreen sends an update call to ServiceRequestService to toggle the active/inactive status of the checklist.
ServiceRequestService returns the updated response.
CurrentScreen updates the checklist status based on the response.
Access Checklist Create UI
The user accesses the Checklist Create UI.
CurrentScreen parses URL query parameters to determine the campaign name, role, and checklist type.
Fetching Draft Service Requests
CurrentScreen sends a request to MDMSAPI to fetch draft service requests based on the role and type.
MDMSAPI returns the configured draft service requests.
Loading Default Checklist Questions
CurrentScreen checks if there is a template available for the checklist and loads default checklist questions.
User Interaction for Checklist Questions
Users can add, delete, or modify any checklist questions in the UI.
The user clicks on "Create" to finalise the checklist.
Generating Unique Codes and Creating Service Requests
CurrentScreen generates a unique code for every checklist question.
CurrentScreen sends a create service request with the list of all questions to ServiceRequestService.
ServiceRequestService returns a successful response indicating that the checklist has been created.
Localisation of Checklist Questions
CurrentScreen sends a request to LOCAPI to create localisation for all checklist questions.
Each question is assigned a generated code, a user-entered message, and is associated with the hcm-checklist module.
LOCAPI processes the localisation request and returns a response.
Completion and Feedback
CurrentScreen displays a toast notification to the User indicating the successful creation of the checklist.
User is redirected back to the Checklist View screen, where they can see the newly created checklist.
Service Request Failures: If a service request fails at any point, the CurrentScreen will display an error message to the User. Users must resolve the issues and retry the operation.
Validation Errors: During checklist creation, if validation errors are detected, the CurrentScreen will notify the User with specific details, and the user must correct the issues before proceeding.
This documentation provides a comprehensive overview of the checklist management process within a campaign. The structured sequence ensures that all checklist-related activities are handled correctly, from viewing existing checklists to creating and localizing new ones. By adhering to this flow, users can manage checklists efficiently, ensuring consistency and accuracy in their campaign management activities.
This document describes the web flow for updating an existing campaign using the Admin Console. The process involves interactions between the user and several backend services, ensuring the campaign data is updated correctly and validated before finalizing changes.
User: The person interacting with the Admin Console to update an existing campaign.
CampaignManager (Admin Console): The primary interface that the user uses to manage and update campaign information.
ProjectFactory: Responsible for handling the creation and updating of campaign objects and validating the data.
BoundaryService: Provides the boundary hierarchy definitions and relationship data necessary for the campaign.
MDMSService: Supplies master data such as project types, hierarchy configurations, and other templates.
FileStoreService: Manages the storage and retrieval of files related to the campaign.
User: Begins the update process by selecting an existing campaign from the "My Campaign" screen within the Admin Console.
CampaignManager: Receives the request to update a specific campaign and retrieves the campaign object using its unique ID.
CampaignManager sends a request to ProjectFactory to fetch the campaign object based on the provided campaign ID.
ProjectFactory responds with the campaign object containing the current campaign details.
CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the campaign's hierarchy type.
BoundaryService responds with the boundary hierarchy definition.
CampaignManager requests BoundaryService to fetch boundary relationship data based on the hierarchy type.
BoundaryService responds with the boundary relationship data.
User: Updates the necessary fields, such as boundary delivery configuration and other campaign-specific details, using the Admin Console.
CampaignManager: Sends the updated information to ProjectFactory to create or update the campaign object, storing it with an action status of "draft".
ProjectFactory: Automatically triggers the generation of templates for different resources, including:
Target templates
Facility templates
User templates
User: Downloads the generated templates for each resource type via the Admin Console.
CampaignManager: Sends a request to FileStoreService to store the downloaded files.
FileStoreService responds with a filestoreid that uniquely identifies the stored file.
CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.
ProjectFactory responds with a unique validation ID, as the validation process may take some time.
CampaignManager: Periodically checks the validation status using the unique validation ID.
ProjectFactory:
If validation is successful:
Responds with a success message.
CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.
If validation fails:
Responds with an error message detailing the validation failure.
CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.
User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Update Campaign" button.
CampaignManager: Sends a request to ProjectFactory with the campaign update API, marking the action as "update".
ProjectFactory:
If the update is successful:
Responds with a success message, indicating that the campaign update has started.
CampaignManager: Displays a success message to the user, confirming that the campaign has been updated successfully.
If the update fails:
Responds with an error message detailing the failure.
CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.
Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.
Service Errors: If any of the services (e.g., BoundaryService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.
This document outlines the flow for updating an existing campaign using the Admin Console. The structured sequence ensures that any changes to the campaign are thoroughly validated and processed, minimizing errors and ensuring the integrity of the campaign data. By following this flow, users can confidently update campaigns, knowing that all necessary steps are taken to verify and finalize their changes.
This document details the web flow for creating a new campaign using the Admin Console. The process involves interactions between various services, including the Project Factory, Boundary Service, MDMS Service, FileStore Service, and the Admin Console. This flow ensures that all necessary data is collected, validated, and processed to create a campaign successfully.
User: The person interacting with the Admin Console to set up and create a campaign.
CampaignManager (Admin Console): The main interface that the user interacts with to manage campaign creation.
ProjectFactory: Handles the creation and management of campaign objects and validation processes.
BoundaryService: Provides information about boundary hierarchy and relationships.
MDMSService: Supplies master data such as project types, hierarchy configurations, and operator details.
FileStoreService: Manages the storage and retrieval of files related to the campaign.
User: Initiates the process by visiting the Admin Console to set up a new campaign.
CampaignManager: Receives the request to set up a campaign and starts interacting with various services to gather necessary information.
CampaignManager sends a request to MDMSService to fetch required master data, including:
Project types
Hierarchy type configuration
Operator templates
Other necessary templates
MDMSService responds with the requested master data, which is used to configure the campaign.
CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the selected hierarchy type.
BoundaryService responds with the boundary hierarchy definition.
CampaignManager requests BoundaryService to fetch boundary relationship data based on the selected hierarchy type.
BoundaryService responds with the boundary relationship data.
User: Fills in the required data such as boundary delivery configuration and other campaign-specific details within the Admin Console.
CampaignManager: Sends the user-filled information to ProjectFactory to create a campaign object and stores it with an initial action status of "draft".
ProjectFactory: Automatically triggers the generation of templates for different resources, including:
Target templates
Facility templates
User templates
User: Downloads the generated templates for each resource type through the Admin Console.
CampaignManager: Sends a request to FileStoreService to store the downloaded files.
FileStoreService responds with a filestoreid that uniquely identifies the stored file.
CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.
ProjectFactory responds with a unique validation ID as the validation process may take some time.
CampaignManager: Periodically checks the status of the validation using the unique validation ID.
ProjectFactory:
If validation is successful:
Responds with a success message.
CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.
If validation fails:
Responds with an error message detailing the validation failure.
CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.
User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Create Campaign" button.
CampaignManager: Sends a final request to ProjectFactory with the campaign creation API, marking the action as "create".
ProjectFactory:
If the creation is successful:
Responds with a success message indicating that the campaign creation has started.
CampaignManager: Displays a success message to the user, confirming the campaign creation.
If the creation fails:
Responds with an error message detailing the failure.
CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.
Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.
Service Errors: If any of the services (e.g., BoundaryService, MDMSService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.
This document outlines the end-to-end flow for creating a new campaign using the Admin Console. It ensures that the user provides all required information, and that data is validated and processed correctly to create the campaign. This structured approach minimizes errors and ensures that all campaigns are set up with the required accuracy and completeness.
