Here are the articles in this section:

• User Interface Design

• Create New Campaign

• Change Campaign Dates

• My Campaign

• Boundary Bulk Upload

• Campaign Timeline

Below are the configurations needed for successfully setting up the campaign module:

MDMS Configuration

• citymodule needed to run campaign module in an environment:

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/tenant/citymodule.json

{
      "module": "Campaign",
      "code": "Campaign",
      "active": true,
      "order": 10,
      "tenants": [
        {
          "code": "mz"
        }
      ]
    },

• roleactions config needed for the user for all campaign access

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/ACCESSCONTROL-ROLEACTIONS/roleactions.json

• actionTest config needed for sidebar action and user access for services

  LINK: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/ACCESSCONTROL-ACTIONS-TEST/actions-test.json

  To enable action in the sidebar, add navigationUrl and path to the object:

{
      ```
      "path": "1Campaign.Mycampaign",
      "navigationURL": "/workbench-ui/employee/campaign/my-campaign",
      "leftIcon": "dynamic:EstimateIcon",
      "rightIcon": ""
    },

Refer to the below ID's link in QA:

• 1528

• 1763

• 1764

• 1765

• 1766

• 1767

• 1768

• 1769

• 1770

• 1771

• 1772

• 1773

• 1774

• 1775

• 1776

• 1777

• roles need to be added in roles

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/ACCESSCONTROL-ROLES/roles.json

{
      "code": "CAMPAIGN_MANAGER",
      "name": "Campaign Manager",
      "description": "Campaign Manager"
    }

• Boundary Schema config needs to be added for boundary sheet validation:

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/health/hcm-admin-console/boundarySchema.json

• Facility Schema config needs to be added for facility sheet validation:

  Link:https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/health/hcm-admin-console/facilitySchema.json

• User schema config needs to be added for user sheet validation:

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/health/hcm-admin-console/userSchema.json

• A hierarchy config needs to be added to define a lowset hierarchy in boundary selection:

  Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/health/hcm-admin-console/hierarchyConfig.json

DevOps Configuration

• Global configuration needs to be added to environments.

  Link: https://github.com/egovernments/DIGIT-DevOps/blob/unified-env/deploy-as-code/helm/environments/unified-uat.yaml

• Helm chart needs to be added in DevOps.

  Link: https://github.com/egovernments/DIGIT-DevOps/blob/unified-env/deploy-as-code/helm/charts/frontend/workbench-ui/Chart.yaml

• Refer here to learn more about the setup environment.

Localisation

This allows users to fill in all the campaign details and create a new campaign.

Click on the following links to learn more:

In the Campaign Details section, there are 4 screens:

• Campaign Type

• Campaign Name

• Campaign Dates

• Campaign Details Summary

1. Campaign Type

This is the first screen when the user clicks on "set-up campaign". In this screen, the user can select the campaign type, and the beneficiary will be prepopulated from the MDMS. This field is mandatory to set up a campaign.

2. Campaign Name

This screen comes after the campaign type. This step is crucial for saving your campaign as a draft, as the name serves as a unique identifier. After clicking on 'Next', the name will be saved and the user can check from the draft.

3. Campaign Dates

This screen asks a user to fill in the start and end dates of the campaign.

4. Summary

This screen will show the summary of the campaign details screen

Api Details

In this step, the user will encounter 2 screens:

• Boundary Details

• Boundary Details Summary

Boundary Details

This screen allows users to select the boundaries according to their requirements.

The working of this screen is as follows:

We will fetch the boundary data according to the hierarchy saved in the MDMS.

The hierarchy structure and the lowest boundary will be fetched from the MDMS

This screen will be shown using the component

Which internally calls the - Selecting boundary component

Validation: The user must select boundaries till the lowest level. If the parent boundary is selected, then the user should select at least one of its child.

Boundary Details Summary

This screen displays all the boundaries selected in the previous step.

Localisation Details

Boundary localisation for this screen happens by using the combination of hierarchy type and boundary type

It should be in this format.

API Details

In the 'Delivery Details' step, users encounter 3 screens:

• Cycles & Deliveries

• Delivery Screen

• Summary

1. Cycle Configuration Screen

On this screen, users specify the number of cycles and deliveries. The number of cycles must be at least 1 and can be up to 5. Once the user has defined the number of cycles and deliveries, they can proceed to enter the start and end dates for each cycle.

The number of cycles and deliveries are configurable based on project type. We can configure it in MDMS:

Link:

If data is configured, a user will see the number of cycles and deliveries as per the configuration. A user, however, can increase or decrease if they find it necessary.

The validations added for the start date and the end date of the cycles should not overlap to each other.

After filling in all the cycle details, a user can click on 'Next' and move to the delivery rules screen. Clicking on 'Next' enables a user to store the cycle data in the local storage.

2. Delivery Screen

On this screen, users fill in all the delivery details (adding delivery rules, adding conditions in delivery rules, adding products in the delivery rules) of each cycle and delivery that the user has selected in the cycle details screen.

The delivery screen can also be configured based on project type. A user can configure the number of delivery conditions, their attributes, and products. If the data is configured correctly, a user can see the data preloaded in delivery rules and the user can change, remove, or add, if they find it necessary.

A user can add delivery rules up to 5. A user can add conditions in each delivery rule with attribute options having height, weight, gender, and age. For Project type, LLIN-mz configuration is passed in delivery rules in which two fixed attributes are present for the bednet campaign.

After filling in all the delivery rules details, when a user clicks on next, the data will be stored in the localStorage as well as in the draft API. The delivery rules data will be validated in the preview screen.

Reference files:

Select or Create a Product

If you click on configure resources on the delivery screen, a pop-up appears where a user can either select or create a product:

Product Screen: When a user clicks on "Add Products to be Delivered", a pop-up screen will appear with a list of product variants where a user can add the products and the number of counts in the delivery rules.

A user can add multiple products to the product screen after clicking on "add more resources" When the user clicks on confirm resources, products will be added to the delivery rules. The user can remove the products as well.

If the product is not present, a user can click on "Add New Product" to create a new product and variant, and subsequently add delivery rules. Clicking on "Add New Product" will open the Create Product screen.

Users can enter product names, product variants, and product types which are sourced from MDMS data. Additionally, a user can create multiple products using the "Add Products" button. After clicking on 'Confirm,' the product will be created, followed by the creation of product variants.

After successful creation, users will be directed to a success response screen.

3. Summary

This screen will show the values the user has added in the cycle configuration screen and delivery screen.

Guide on Setting Up Delivery Configuration for the screen.

This MDMS schema is used to fetch the details for every product type, to convert the data to the required format used by the screen, we are writing the util.

The following is the structure for the delivery configuration:

• projectType: This will be the type of the project. If the selected project type is present in the MDMS, then we use that config.

• attrAddDisable: if this is true, we are restricting a user that they cannot add any attribute.

• deliveryAddDisable: if this is true, a user cannot add any further delivery rule conditions.

• cycleConfig: This will be an object containing cycles and deliveries. This refers to the number of cycles and deliveries that will be shown on the cycle screen.

• deliveryConfig: This will be an array of objects, each object representing one delivery condition.

Adding product config is a careful job, adding the wrong product in the config will cause issues while creating a product.

In Value, the product variant ID should be added in the value which will be getting in the below API:product/variant/v1/_search

The name will consist of the name of the product and the variant of the product separated with "-"

for name: product/v1/_search

for variant: product/variant/v1/_search

FilePath:

Reference links:

MDMS:

HOOKS:

New changes

We have added the Delivery type at each delivery condition showing the delivery type of the campaign.

It is configurable in mdms for the SMC project type. We can add a default delivery type for each condition.

deliveryConfig: It will contain the default data of all deliveries.

conditionConfig: It will contain default data of each delivery condition of each delivery.

deliveryType: Default value of delivery type.

API Details

The logic for the step-by-step screens, stepper functionality, storing data in localStorage, creating/updating campaigns, and restructuring API data back into localStorage is all managed within SetupCampaign.js.

https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js

All screens are present in the given configuration. Link: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/configs/CampaignConfig.js

In the configuration:

• stepCount represents the step number. Multiple configuration objects can share the same stepCount.

• skipAPICall: If this is set to true, the API call for the screen is skipped.

• sessionData: Local storage data is passed in custom props, allowing for custom logic to be added to the screens as needed.

export const CampaignConfig = (totalFormData, dataParams) => {
  return [
    {
      form: [
        {
          stepCount: "1",
          key: "1",
          name: "HCM_CAMPAIGN_TYPE",
          body: [
            {
              isMandatory: false,
              key: "projectType",
              type: "component",
              skipAPICall: true,
              component: "CampaignSelection",
              withoutLabel: true,
              disable: false,
              customProps: {
                module: "HCM",
                sessionData: totalFormData,
              },
              populators: {
                name: "projectType",
              },
            },
          ],
        },
        ``````

In setup campaign, we have functions to perform specific logic:

• loopAndReturn: This function takes the delivery rule conditions coming from API response and restructure the data in local storage format.

• cycleDataRemap: This function takes the delivery rules data coming from API response and return array of object of start date and end date based on cycles.

• reverseDeliveryRemap: This function takes the deliveryConditions from the API response and return the structure of delivery data.

• groupByTypeRemap: This function creates the local structure of boundaries.

• updateUrlParams: This function is used to update the URL.

New Campaign & Implementing Local Storage

• In a new campaign, we update the total form when a user clicks on next after entering the data.

• After updating the total form data, we store the data in localStorage.

• We also call the API to draft the data in case a user wants to come back and resume the campaign.

• Refer to the following link:

https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js#L545

Draft Campaign & Data Fetching

• When a user clicks on the draft campaign, he/she can fetch campaign data from the response.

• After getting a response, one can restructure the data in screen format and store it in the local storage.

• After updating, the user is redirected to the last screen where additional details are stored in response.

• Refer to the following link:

https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js#L327

Stepper

• Based on screens, a user can filter the configuration and show the stepper based on the configuration.

• Refer to the following link:

https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js#L1159

New Changes:

As part of v0.3, we have introduced a new vertical stepper and summary screens for all the steps.

The vertical steppers are clickable and the user can navigate between the screens using the steppers.

Summary screens will show all the details entered by the user in that step.

Overview

The "Setup Campaign" feature facilitates the creation of a campaign using an approved microplan. It ensures that only authorized users can initiate the setup process, generates required campaign data, and integrates with external APIs to fetch user, facility, and target data.

. User Role Validation

• Role Required: MICROPLAN_CAMPAIGN_INTEGRATOR

• Validation Logic:

  • Only users with the above role can select an approved microplan to initiate the campaign setup.

  • If the user lacks the role, access to the feature is denied with a proper error message.

Campaign Object Creation

• Input: Approved microplan object.

• Steps:

  1. Extract the base campaign object from the selected microplan.

  2. Create a new campaign object by cloning the base campaign object with the following updates:

     • Add unique identifiers (campaignId, createdBy).

     • Set the campaign status to draft.

  3. Save the new campaign object to the backend.

Generate Empty Templates

• Trigger: After updating the campaign object with selected boundaries, it gets auto-generated from Backend

• Steps:

  1. Automatically generate empty templates for the campaign, including:

     • User assignments.

     • Facility data placeholders.

     • Target data placeholders.

Fetch Data from Microplan API

• API Endpoint: project-factory/v1/project-type/fetch-from-microplan

• Steps:

  1. Call the Microplan API to fetch:

     • User data.

     • Facility data.

     • Target data.

  2. Populate the empty templates with the fetched data.

  3. Save the updated templates back to the backend.

Campaign Search Polling

• Purpose: Monitor the progress of data population and transition to the next step once completed.

• Steps:

  1. The UI triggers a periodic call to the campaignSearch endpoint:

     • API Endpoint: /campaign-search

     • Parameters: campaignId.

  2. Check the status of the campaign:

     • If Completed:

       • Navigate the user to the Setup Campaign page.

     • If In Progress:

       • Re-trigger the data fetch from Microplan API to ensure completion.

       • Continue polling.

Navigation to "Setup Campaign" Page.

• Steps:

  1. Transition the user to the Setup Campaign page.

  2. Pass the necessary campaign data as route parameters or via state management.

API Details:

The resource upload details consists of 3 types of uploads:

• Upload Target Data

• Facility Upload

• User Upload

• Upload Summary

1. Upload Target Data

This screen will come after a user selects the boundaries.

When a user clicks on the download template button, an Excel will get downloaded which will contain readMe, Boundary Data sheet along with the sheets with districts, where the user has to fill the target at the lowest level. After the file is uploaded, it will go for validation. Once validated, a user can go to the next page, where the user can delete the file and move to the next page to upload facility date.

2. Upload Facility Data

This screen will come after the target upload screen.

In this screen, when a user clicks on the download template, an Excel gets downloaded containing readMe, Facility sheet, and BoundaryData sheet. A user has to fill in the boundary codes and from that sheet, the user has to fill in the facility sheet.

3. Upload User Data

This screen will appear after the facility details screen.

When a user clicks on the download template, an Excel file gets downloaded that consists of readMe, User Sheet, and BoundaryData. The user has to fillout the user sheet only.

All the 3 downloads are happening through the Generate and Download APIs. For the Generate API, the following hook is used: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/hooks/useGenerateIdCampaign.js

This hook will return the ID which is stored in the local storage according to the type:

HCM_CAMPAIGN_MANAGER_UPLOAD_ID

Next, /project-factory/v1/data/_download is used to download the template.

4. Summary

This screen displays all the files which were uploaded in the previous screens, Validation in this screen -

All the 3 files are mandatory to upload in this step otherwise the user is not allowed to move to the next step.

Schema Validation

After uploading the templates, UI validation is done through schema stored in the MDMS: Schema Data link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/adminSchema.json

Schema Module = adminSchema Below is the admin schema-

 "SchemaDefinitions": [
        {
            "id": "92fb3b53-adfe-44e9-ab27-da3209b5e0f1",
            "tenantId": "mz",
            "code": "HCM-ADMIN-CONSOLE.adminSchema",
            "description": null,
            "definition": {
                "type": "object",
                "title": "Comprehensive Example Schema",
                "$schema": "http://json-schema.org/draft-07/schema#",
                "required": [
                    "$schema",
                    "title",
                    "campaignType"
                ],
                "x-unique": [
                    "title",
                    "campaignType"
                ],
                "properties": {
                    "title": {
                        "type": "string"
                    },
                    "$schema": {
                        "enum": [
                            "http://json-schema.org/draft-07/schema#"
                        ],
                        "type": "string",
                        "default": "http://json-schema.org/draft-07/schema#"
                    },
                    "properties": {
                        "type": "object",
                        "properties": {
                            "enumProperties": {
                                "type": "array",
                                "items": {
                                    "type": "object",
                                    "required": [
                                        "name",
                                        "description"
                                    ],
                                    "properties": {
                                        "enum": {
                                            "type": "array",
                                            "items": {
                                                "type": "string"
                                            }
                                        },
                                        "name": {
                                            "type": "string"
                                        },
                                        "isUnique": {
                                            "type": "boolean"
                                        },
                                        "hideColumn": {
                                            "type": "boolean"
                                        },
                                        "isRequired": {
                                            "type": "boolean"
                                        },
                                        "description": {
                                            "type": "string"
                                        },
                                        "orderNumber": {
                                            "type": "integer",
                                            "minimum": 1
                                        },
                                        "errorMessage": {
                                            "type": "string"
                                        },
                                        "freezeColumn": {
                                            "type": "boolean"
                                        }
                                    },
                                    "minProperties": 1
                                },
                                "minItems": 1
                            },
                            "numberProperties": {
                                "type": "array",
                                "items": {
                                    "type": "object",
                                    "required": [
                                        "name",
                                        "description"
                                    ],
                                    "properties": {
                                        "name": {
                                            "type": "string"
                                        },
                                        "type": {
                                            "enum": [
                                                "number"
                                            ],
                                            "type": "string"
                                        },
                                        "maximum": {
                                            "type": "number"
                                        },
                                        "minimum": {
                                            "type": "number"
                                        },
                                        "isUnique": {
                                            "type": "boolean"
                                        },
                                        "hideColumn": {
                                            "type": "boolean"
                                        },
                                        "isRequired": {
                                            "type": "boolean"
                                        },
                                        "multipleOf": {
                                            "type": "number"
                                        },
                                        "description": {
                                            "type": "string"
                                        },
                                        "orderNumber": {
                                            "type": "integer",
                                            "minimum": 1
                                        },
                                        "errorMessage": {
                                            "type": "string"
                                        },
                                        "freezeColumn": {
                                            "type": "boolean"
                                        },
                                        "exclusiveMaximum": {
                                            "type": "boolean"
                                        },
                                        "exclusiveMinimum": {
                                            "type": "boolean"
                                        }
                                    },
                                    "minProperties": 1
                                },
                                "minItems": 1
                            },
                            "stringProperties": {
                                "type": "array",
                                "items": {
                                    "type": "object",
                                    "required": [
                                        "name",
                                        "description"
                                    ],
                                    "properties": {
                                        "name": {
                                            "type": "string"
                                        },
                                        "type": {
                                            "enum": [
                                                "string"
                                            ],
                                            "type": "string"
                                        },
                                        "pattern": {
                                            "type": "string",
                                            "format": "regex"
                                        },
                                        "isUnique": {
                                            "type": "boolean"
                                        },
                                        "maxLength": {
                                            "type": "integer",
                                            "minimum": 0
                                        },
                                        "minLength": {
                                            "type": "integer",
                                            "minimum": 0
                                        },
                                        "hideColumn": {
                                            "type": "boolean"
                                        },
                                        "isRequired": {
                                            "type": "boolean"
                                        },
                                        "description": {
                                            "type": "string"
                                        },
                                        "orderNumber": {
                                            "type": "integer",
                                            "minimum": 1
                                        },
                                        "errorMessage": {
                                            "type": "string"
                                        },
                                        "freezeColumn": {
                                            "type": "boolean"
                                        }
                                    },
                                    "minProperties": 1
                                },
                                "minItems": 1
                            },
                            "additionalProperties": {
                                "type": "boolean"
                            }
                        },
                        "additionalProperties": false
                    },
                    "campaignType": {
                        "type": "string"
                    }
                },
                "description": "A simplified JSON Schema example based on data type.",
                "additionalProperties": false
            },
            "isActive": true,
            "auditDetails": {
                "createdBy": "8b110055-330f-4e7b-b4c0-f618f29b9d47",
                "lastModifiedBy": "8b110055-330f-4e7b-b4c0-f618f29b9d47",
                "createdTime": 1718169189364,
                "lastModifiedTime": 1718169189364
            }
        }
    ]

By using AJV Validation , we are validating the headers of the facility sheet. We are also doing some basic validations for the data such as-

• Facility Type can only be Warehouse/Health Facility

• Facility Name can only be string

• Facility Status can only be Temporary or Permanent etc.

Apart from this, we are also validating sheet names in all the 3 uploads.

For target validation, we use schema only for validating the header of the target and boundary codes. Here, we also validate the target at the lowest level, where the value should be between:

targetValue <= 0 || targetValue >= 100000000

Validation API Call:

Before calling we are using base time out which is fetched from the MDMS

For more information on this schema, you can refer to:

https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/baseTimeOut.json

Reference Links:

For the backend validation, we use the following hook: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/hooks/useResourceData.js

The screens are using the given below components for upload and validation-

Bulk upload: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/BulkUpload.js

Preview component: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/XlsPreview.js

File screen: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/UploadData.js

API Details

New Features:

A new pop-up has been added which displays the option to download the template in all three upload screens.

Use Case:

when the user comes after clicking next on the delivery screen and the file is not uploaded then this pop-up is displayed.

The summary screen provides users with a view of all campaign details entered.

Users can review the entirety of their campaign information. If the campaign status is marked as 'drafted,' users can either edit the existing data or submit it. After submission, the campaign is created, initiating the 'create' action.

For campaigns in a 'draft' status, the summary screen serves as the final step of the campaign setup process, giving users the option to edit or submit the details before finalisation.

If the campaign is successfully created while in the 'draft' status, users are directed to a success screen.

After the API call, the data undergoes restructuring to present delivery rules based on the cycle and delivery details.

FilePath: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/CampaignSummary.js

API Details:

For draft status only:

For IRS to be displayed as the campaign type , initially it needs to added in the MDMS. Master name: projectTypes Module name: "HCM-PROJECT-TYPES" https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/project-types.json

Changes in delivery details:

The delivery configuration in the MDMS needs to be updated. The desired properties will show the attributes, operator, and value.

For the IRS campaign type, the number of cycles and the number of deliveries will not be editable.

To make the cycle and deliveries not editable, we need to pass one flag in the delivery configuration.

 "IsDisable": true

The delivery conditions page will be shown like this in which values will come from the MDMS.

Master name: HOUSE_STRUCTURE_TYPES

Module name: HCM

For the target templates to be generated dynamically, data needs to be added in the adminSchema.

 "schemaCode": "HCM-ADMIN-CONSOLE.adminSchema"

{
                "title": "boundary",
                "$schema": "http://json-schema.org/draft-07/schema#",
                "properties": {
                    "numberProperties": [
                        {
                            "name": "HCM_ADMIN_CONSOLE_TARGET_IRS_1",
                            "type": "number",
                            "isRequired": true,
                            "description": "Target at the Selected Boundary Level",
                            "orderNumber": 2
                        },
                        {
                            "name": "HCM_ADMIN_CONSOLE_TARGET_IRS_2",
                            "type": "number",
                            "isRequired": true,
                            "description": "Target at the Selected Boundary Level",
                            "orderNumber": 3
                        }
                    ],
                    "stringProperties": [
                        {
                            "name": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE",
                            "type": "string",
                            "isRequired": true,
                            "description": "Boundary Code",
                            "orderNumber": 1,
                            "freezeColumn": true
                        }
                    ]
                },
                "campaignType": "IRS-mz"
            },
            "isActive": true,
            "auditDetails": {
                "createdBy": "bfab6822-ec28-40f0-aef1-efd1cda8fcd5",
                "lastModifiedBy": "bfab6822-ec28-40f0-aef1-efd1cda8fcd5",
                "createdTime": 1722846607391,
                "lastModifiedTime": 1722846607391
            }
        },
        {
            "id": "87d17bf5-b0dd-4796-a36f-32e466c47569",
            "tenantId": "mz",
            "schemaCode": "HCM-ADMIN-CONSOLE.adminSchema",
            "uniqueIdentifier": "boundaryWithTarget.IRS-mz",
            "data": {
                "title": "boundaryWithTarget",
                "$schema": "http://json-schema.org/draft-07/schema#",
                "properties": {
                    "numberProperties": [
                        {
                            "name": "HCM_ADMIN_CONSOLE_TARGET_IRS_1",
                            "type": "number",
                            "isRequired": true,
                            "description": "Target at the Selected Boundary Level",
                            "orderNumber": 2
                        },
                        {
                            "name": "HCM_ADMIN_CONSOLE_TARGET_IRS_2",
                            "type": "number",
                            "isRequired": true,
                            "description": "Target at the Selected Boundary Level",
                            "orderNumber": 3
                        }
                    ],
                    "stringProperties": [
                        {
                            "name": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE",
                            "type": "string",
                            "isRequired": true,
                            "description": "Boundary Code",
                            "orderNumber": 1,
                            "freezeColumn": true
                        }
                    ]
                },
                "campaignType": "IRS-mz"
            },
            "isActive": true,
            "auditDetails": {
                "createdBy": "bfab6822-ec28-40f0-aef1-efd1cda8fcd5",
                "lastModifiedBy": "bfab6822-ec28-40f0-aef1-efd1cda8fcd5",
                "createdTime": 1722846554092,
                "lastModifiedTime": 1722846554092
            }
        }

Overview

My campaign screen allows users to see the list of campaigns that are in Ongoing, Completed, or Draft status. Users can search campaign by using the campaign name or campaign type. Users can also see a summary of the campaign and complete the campaign creation if it is draft status.

The list of statuses showing in the "My Campaign" screen are:

1. Ongoing

2. Completed

3. Drafts

4. Failed

5. Upcoming

User actions

After clicking on the My Campaign link from the HCM Campaign module card, the user lands on the My Campaign screen where the user can see all the lists of campaigns of each action in the tab.

File Path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/MyCampaign.js

On my campaign screen, we are sending the payload:

• Campaigns with an end date that has passed the current date are marked as 'Completed'.

• Campaigns with a status of 'Started' and no end date, or with an end date in the future, are labeled as 'Ongoing'."

• The logic is written in UICustomizations.js

• File path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/configs/UICustomizations.js

Clicking on campaigns other than draft status will redirect to the summary page of the campaign where the user can see the complete details of the respective campaign.

File Path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/CampaignSummary.js

Ongoing Campaign Filtering

For the ongoing campaign filtering functionality, we are utilizing the campaignsIncludeDates parameter set to true. The startDate and endDate parameters are both set to the current date. This configuration ensures that the API will return any campaign where the specified startDate or endDate falls within the campaign's defined start and end dates. Additionally, the campaign status is filtered to include campaigns with statuses of created or creating.

Parameters

• campaignsIncludeDates: This boolean parameter is set to true to enable date range filtering.

• startDate: The start date for the filter, is set to today's date.

• endDate: The end date for the filter, is also set to today's date.

• status: The campaign status filter, including the statuses created and creating.

Implementation

To filter the ongoing campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:

{ 
   "campaignsIncludeDates": true, 
   "startDate": "", // Use the current epoch date dynamically 
   "endDate": "2024-05-23", // Use the current epoch date dynamically 
   "status": ["created", "creating"] 
}

Logic Explanation

• campaignsIncludeDates = true: This activates the date range filtering feature.

• startDate and endDate = today: By setting both the start and end dates to today's date, the filter will capture any campaigns that are active today.

• status = ["created", "creating"]: Filters the campaigns to only include those that are currently in the created or creating status.

Completed Campaign Filtering

For filtering completed campaigns, we use a similar approach with a slight modification to the date parameters and status. Specifically, we will set the endDate parameter to yesterday's date. This configuration ensures that the API returns campaigns that have ended as of yesterday. The statuses to filter will remain creating and created.

Parameters

• endDate: The end date for the filter, is set to yesterday's date.

• status: The campaign status filter, including the statuses creating and created.

Implementation

To filter the ongoing campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:

{
   "endDate": "", // Use the yesterday epoch date dynamically 
   "status": ["created", "creating"] 
}

Logic Explanation

1. endDate = yesterday: By setting the end date to yesterday's date, the filter will capture any campaigns that have ended by the end of the previous day.

2. status = ["created", "creating"]: Filters the campaigns to include only those that were in the created or creating status when they ended.

When a user clicks on the completed campaign, they will be redirected to the summary page displaying the campaign details. The success toast message will appear If the user credential sheet is generated successfully. Users can view or download the sheet from the user credential card or download button which appears at the top.

Upcoming Campaign Filtering

For filtering upcoming campaigns, we use a different approach by setting the campaignsIncludeDates parameter to false and specifying the startDate parameter to tomorrow's date in epoch format. This configuration ensures that the API returns campaigns scheduled to start tomorrow. The statuses to filter will remain creating and created.

Parameters

• campaignsIncludeDates: This boolean parameter is set to false as we are not filtering based on a date range but rather a specific start date.

• startDate: The start date for the filter, is set to tomorrow's date in epoch format.

• status: The campaign status filter, including the statuses creating and created.

Implementation

To filter the upcoming campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:

{
  "campaignsIncludeDates": false,
  "startDate": 1716748800,  // Use tomorrow's epoch date dynamically
  "status": ["created", "creating"]
}

Logic Explanation

1. campaignsIncludeDates = false: This deactivates the date range filtering feature, focusing the filter on a specific start date.

2. startDate = tomorrow (epoch date): By setting the start date to tomorrow's date in epoch format, the filter will capture any campaigns scheduled to start tomorrow.

3. status = ["created", "creating"]: Filters the campaigns to include only those that are in the created or creating status and scheduled to start tomorrow.

When a user clicks on an upcoming campaign, they will be redirected to the summary page displaying the campaign details.

Drafts Campaign Filtering

For the drafts campaign, we are passing the status as drafted. It will return all the drafts that are in drafted status

Failed Campaign Filtering

For failed campaigns, we are passing the status as failed. It will return all the drafts that are in failed status

When a user clicks on a failed campaign, they will be redirected to the summary page displaying the campaign details. Additionally, a toast message will appear, showing the error that caused the campaign to fail.

MDMS

Path: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/project-types.json

API Details

A new 'Actions' column has been added to the "My Campaign" screen, allowing users to perform some tasks skillfully.

Users can click on 'Actions' to choose from the available action options in the menu.

Implementation:

We've added config for column actions in myCampaignConfig.js

 {
                label: "CAMPAIGN_ACTIONS",
                jsonPath: "actions",
                additionalCustomization: true,
 }

In UICustomization.js, we have added a component that needs to be rendered for the action column under additionalCustomizations.

case "CAMPAIGN_ACTIONS":
          return (
              <Button
                className="custom-className"
                type="actionButton"
                variation="secondary"
                label={"Action"}
                options={[{ key: 1, code: "OPTION", i18nKey: t("OPTION") }]}
                optionsKey="i18nKey"
                showBottom={true}
                isSearchable={false}
                onOptionSelect={(item) => onActionSelect(item, row)}
              />
          );

We have added an onActionSelect function which acts based on the selected option.

Actions are different according to the different campaign status

File Path:

https://github.com/egovernments/DIGIT-Frontend/blob/8e56e756453222445162013fec7d16ab227b85c5/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/MyCampaign.js

Config:

https://github.com/egovernments/DIGIT-Frontend/blob/f00410f4d8198d8eebfaf7d7655661c64aff2397/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/configs/myCampaignConfig.js

UICustomisation:

https://github.com/egovernments/DIGIT-Frontend/blob/8e56e756453222445162013fec7d16ab227b85c5/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/configs/UICustomizations.js

Overview

The timeline provides a visual representation of the campaign creation process. It can be accessed from the summary or through the action button on the "My Campaign" screen. The timeline will be shown for ongoing, upcoming, completed, and failed campaigns.

Summary

This timeline shows all the stages of the campaign that are successfully created. A user can download the user credentials as soon as the campaign is created successfully.

The above images show all three timeline steps: upcoming, current, and completed.

My Campaign

A user can also access the timeline from the "My Campaign" screen by clicking on the action button present in the search result.

The timeline will be shown as a pop-up from the "My Campaign" screen. Similar to the summary, while the campaign creation is in progress, it will display all the steps such as upcoming, current, and completed. User credentials will be downloaded once the campaign is successfully created.

File Path:

API Details

This flow allows the user to update campaign boundary, facility, user, and target details once the campaign is created.

Users can go to update campaign flow from the action button present in my campaigns screen.

Updating the campaign is possible only for ongoing and upcoming campaigns.

Screens coming for this update campaign are-

• Selecting Boundary

• Update Facility details

• Update User details

• Update Target

• Summary

1. Selecting Boundary

This is the first screen that is displayed to the user when they try to update the campaign from the My Campaigns screen. This screen is already pre-filled with the boundary data which is selected during the campaign creation.

It is impossible to delete the already selected boundaries, user can always add new boundaries if they want to update.

2. Update Facility Data

This screen allows the user to update the facility details:

When the user downloads the current facility template, then that template is already filled with the facility details that the user has entered during the time of campaign creation.

In this user can add the new facilities.

3. Upload User Details

This screen allows the user to update the facility details:

When the user downloads the current user template, then that template is already filled with the user details that the user has entered during the time of campaign creation.

In this user can add a new user.

4. Update Targets

This screen allows the user to update targets:

When the user downloads the current target template then that template is already filled with the target details that the user has entered during the time of campaign creation.

In this user can add the new targets or change the existing ones.

The file path of all the upload screens:

5. Summary

This helps the user to view the summary of all the entered details in the previous screens:

Working of the update campaign flow-

The update campaign flow works similarly to the setup campaign. But the difference is that here we send the parentId in the URL and fetch it from there.

When the user clicks on next after the boundary details screen, the create API is called with parentID in the params and with action = draft. Then for the subsequent steps update API is called. In the summary screen again create API is called again but with action = 'create'. This action updates the campaign.

Validation of the update campaign

1. If no new boundary selected - If the user has not selected any new boundary then, to update the campaign at least one data upload is necessary.

2. New Boundaries Added - If the user has selected new boundaries then all the 3 data uploads are necessary for the user.

API Details

The checklist requires data from mdms which is configurable and have the following schema codes:

Example Data for the above schema codes// Some code```postman_json

User enters the checklist search screen by clicking on the configure app.

The Search Checklist is the screen where u can search for created checklist and also create checklists for whose templates have been created. View button is present for the created checklists and Configure button for those which need to be created.

The Create Checklist page loads the default template for that particular use role and checklist type and then can be edited as per the user. On submission the api creates the checklist (service definition) and create localisation for all the questions and options

The questions can be Single Choice (Radio button) or Multiple Choice (Checkbox) and each single choice option can have multiple sub questions. Nesting is allowed uptil 3 levels. Nesting can be done by clicking on the Dependency button. Options can also have comments attached to them. Add options and delete options feature is also given. The required checkbox is to make any question mandatory.

Preview Checklist shows the mobile view of the created checklist

The View Checklist page shows the current checklist and is non-editable.

The create and update pages work same. The update checklist page loads the already created questions to be edited and can be reached by clicking the update button on view checklist button.

The following API’s are called while checklist creation :

1. Question type search: /mdms-v2/v2/_search this is used to search the types of questions like radio button or checkboxes and these are taken from the mdms with schema code HCM-ADMIN-CONSOLE.appFieldTypes

2. Create: /service-request/service/definition/v1/_create : used to create the service definition which is the checklist.

3. Upsert: /localization/messages/v1/_upsert All the questions and options are localised by this api under the module name hcm-checklist

The following api is called to view the previously created checklist :

1. service-request/service/definition/v1/_search

The following API’s are called while checklist update :

1. Create: /service-request/service/definition/v1/_update : used to update the service definition which is already created.

Boundary Management works based on the HierarchySchema

Refer section to know more

Currently, the default hierarchy name is taken from "type": "default", while the hierarchy where data can be created or edited is defined by "type": "campaign".

The landing page of Boundary Management Screen has three buttons

If the boundary has yet not created then the edit boundary field will be disabled

And clicking on create will ask to use default boundary and data from GeoPoDe or create a complete new one.

Using data from GeoPoDe will load the default boundary and ask to add levels

Creating complete new data will require addition of all levels manually

After creation the levels cannot be edited.

Following API’s are called after clicking the Create button:

1. Upsert: /localization/messages/v1/_upsert all the names of level localised in to new module named hcm-boundary-${hierarchyName}

2. Create: /boundary-service/boundary-hierarchy-definition/_create

3. Download: /project-factory/v1/data/_download A polling mechanism is introduced here which keeps on calling the above api until the status is “completed”

4. Create: /project-factory/v1/data/_create Data create api called if it’s a new hierarchy and here also a polling mechanism is installed which calls the api /project-factory/v1/data/_search continuously at a fixed interval until the status is “completed”

It will automatically redirect to the view hierarchy screen after successful creation. If any level matches with the default hierarchy then it will use its data. Complete excel sheet can be uploaded for all levels all together after downloading the template and uploading it. (The image below is just for reference and levels can vary)

After uploading the excel user can go to next page and view data and confirm it.

Submitting next will create the data.

Submitting next will create the data.

Edit boundary tab on first boundary page will also land to view hierarchy page as of now and will allow to add new data. View all Boundary data will show all hierarchies and user can download the hierarchies too.

Following API is called after clicking “Create Boundary”:

1. Create: /project-factory/v1/data/_create the uploaded data in excel is sent to data create api with polling mechanism applied. The search API /project-factory/v1/data/_search is called repeatedly with frequency depending on the size of data and network latency taken from the mdms data using master name “baseTimeout” from module named HCM-ADMIN-CONSOLEuntil status is “completed”.

API Details

Following is the curl to create a template for:

The user needs to create a template for all the combinations of roles, campaign types, and checklist types for which he/she wants to have a checklist configured.

If any option needs to have sub-questions, then add an optionDependency attribute as true in the option's object. All the questions, whether at the parent or children level, need to be different objects and connected via their parentId which is nothing but the parent option's ID.

Overview

This screen enables users to update the start date, end date, and cycle dates for both ongoing and upcoming campaigns. Additionally, an 'Actions' column has been added to the "My Campaign" screen, providing more options for managing the campaigns.

When a user clicks on 'Actions', they will see the "Update Dates" option. Selecting "Update Dates" redirects the user to the update date screen.

We have added an MDMS configuration flag to determine whether the dates can be updated with or without boundaries. Depending on the MDMS flag, the appropriate screen will be rendered.

Update Dates Based on Boundary

If the MDMS flag for updating dates with a boundary is set to true, the corresponding screen for updating dates will be rendered.

If the MDMS flag for updating with a boundary is set to true, the corresponding screen will be rendered. On this screen, the user first selects the hierarchy level and boundary they wish to update. After making their selection, the user clicks the 'Confirm' button.

Based on the selected boundaries, the corresponding dates are displayed. The user can then change the dates and cycle dates as needed. Fields with dates that have already passed (relative to today) are made non-editable.

After making the desired changes, the user clicks the 'Confirm' button to update the dates. Once the update is successful, a success response screen is shown, and the user is redirected back to the "My Campaign" screen.

Update Dates Without Boundary

If the MDMS flag is set to false, the corresponding screen is rendered to update the dates without considering boundaries, at the root level.

When the user clicks on "Update Date" for the respective campaign, the update date screen is shown with all the prefilled start and end dates. The user can then make the necessary changes.

The user can change the editable dates. Any date fields that have passed the current date are non-editable. Once the user confirms the date change, the data is updated. After a successful update, the user is redirected to a success screen.

File Path:

Hooks

Project Update:

MDMS Link:

API Details

Sample: