egov-mdms-data/data/mz/health/hcm-admin-console/deliveryConfig.json at UNIFIED-QA · egovernments/egov-mdms-dataGitHubLoading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In the 'Delivery Details' step, users encounter 3 screens:
Delivery Dates
Cycle Configuration
Delivery
This screen asks a user to fill in the start and end date of the campaign.
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:
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.
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 which 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:
Delivery rule's screen file path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/deliveryRule/index.js
API call file path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js
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.
Here you can find the config of delivery based on project type.
The following is the structure of 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 in 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:
MDMS:
Bednet config: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/deliveryConfig.json
Product Type: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/productType.json
HOOKS:
We have added Delivery type at each delivery conditions showing the delivery type of the campaign.
It is configurable in mdms for the SMC project type. We can add default delivery type at each conditions.
deliveryConfig: It will contain default data of all deliveries.
conditionConfig: It will contain default data of each delivery condition of each deliveries
deliveryType: Default value of delivery type.
A info card is been added in both the screens in the delivery details. Which states the criteria of delivery as recommended by WHO.
| End Point | Method | Payload |
|---|---|---|
product/variant/v1/_search
POST
{ "ProductVariant": {}, "RequestInfo": { } }
product/v1/_search
POST
{ "Product": { "id": [ "P-2024-01-04-000094", "P-2024-01-04-000094", "P-2024-01-04-000095", "P-2024-01-04-000095", "P-2024-01-04-000096", "P-2024-01-04-000094", "P-2024-01-04-000094", "P-2024-01-04-000095", "P-2024-01-04-000095",] }, "RequestInfo": { } }
product/v1/_create
POST
{ "Product": [ { "tenantId": "mz", "type": "BEDNET", "name": "CHECKTHEONE" } ], "apiOperation": "CREATE", "RequestInfo": { } }
product/variant/v1/_create
POST
{ "ProductVariant": [ { "tenantId": "mz", "productId": "P-2024-05-09-000322", "variation": "1000" } ], "apiOperation": "CREATE", "RequestInfo": { } }
project-factory/v1/project-type/update
POST
{ "CampaignDetails": { "id": "76e7f371-1f85-4739-97dc-feb4ee10fa6b", "tenantId": "mz", "status": "drafted", "action": "draft", "campaignNumber": "CMP-2024-05-09-001413", "campaignName": "TheNewOne", "projectType": "LLIN-mz", "hierarchyType": "ADMIN", "boundaryCode": "", "projectId": null, "startDate": 1716056999000, "endDate": 1716488999000, "additionalDetails": { "beneficiaryType": "HOUSEHOLD", "key": 5 }, "resources": [], "boundaries": [], "deliveryRules": [ { "cycleNumber": 1, "deliveryNumber": 1, "deliveryRuleNumber": 1, "products": [ { "value": "PVAR-2024-01-24-000076", "name": "SP - 500mg", "count": 1 } ], "conditions": [ { "attribute": "CAMPAIGN_BEDNET_INDIVIDUAL_LABEL", "operator": null, "value": null }, { "attribute": "CAMPAIGN_BEDNET_HOUSEHOLD_LABEL", "operator": null, "value": null } ] } ], "auditDetails": { "createdBy": "63a21269-d40d-4c26-878f-4f4486b1f44b", "lastModifiedBy": "63a21269-d40d-4c26-878f-4f4486b1f44b", "createdTime": 1715270852152, "lastModifiedTime": 1715273123616 } }, "RequestInfo": { } }
This allows users to fill in all the campaign details and create a new campaign.
Click on the following links to learn more:
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.
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.
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 take the deliveryConditions from API response and return the structure of delivery data.
groupByTypeRemap: This function create the local structure of boundaries.
updateUrlParams: This function is using to update the url.
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:
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 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:
Based on screens, a user can filter the configuration and show the the stepper based on the configuration.
Refer to the following link:
Overview
In the Campaign Details stepper, there are 2 screens:
Campaign Type
Campaign Name
This is the first screen when the user clicks on the set-up campaign. In this screen, a user can select the campaign type and the beneficiary will be prepopulated from the MDMS. It is a mandatory field to set up a campaign.
Here, the dropdown will show the list of campaign types that are present in the MDMS. We will fetch the MDMS data from:
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.
This screen asks a user to fill in the start and end date of the campaign.
MDMS:
File Path:
File Path:
FilePath:
| End Point | Method | Payload |
|---|
project-factory/v1/project-type/create | POST | { "hierarchyType": "ADMIN", "tenantId": "mz", "action": "draft", "campaignName": "test90", "resources": [], "projectType": "MR-DN", "additionalDetails": { "beneficiaryType": "INDIVIDUAL", "key": 2 } } |
project-factory/v1/project-type/search | POST | { "tenantId": "mz", "ids": [ "2a2491a7-c52d-4305-8b5b-9aa10ae44168" ], "pagination": {} } |
/project-factory/v1/project-type/search | POST | { "tenantId": "mz", "ids": [ "2a2491a7-c52d-4305-8b5b-9aa10ae44168" ], "pagination": {} } |
/project-factory/v1/project-type/update | POST | { "id": "2a2491a7-c52d-4305-8b5b-9aa10ae44168", "tenantId": "mz", "status": "drafted", "action": "draft", "campaignNumber": "CMP-2024-05-15-000496", "campaignName": "test90", "projectType": "MR-DN", "hierarchyType": "ADMIN", "boundaryCode": "", "projectId": null, "startDate": 1715970599000, "endDate": 1717180199000, "additionalDetails": { "beneficiaryType": "INDIVIDUAL", "key": 3 }, "resources": [], "boundaries": [], "deliveryRules": [], "auditDetails": { "createdBy": "21fed2bc-6a73-41b2-b9ae-0996f5b5ede5", "lastModifiedBy": "21fed2bc-6a73-41b2-b9ae-0996f5b5ede5", "createdTime": 1715762971435, "lastModifiedTime": 1715762971519 } } |
The Summary screen provides users with a comprehensive 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.
If campaign data is incomplete and user tries to create a campaign, then we are showing all the erros in the respective card specifyig the error to the user. User can make the change by using errors button or clicking on edit button showing in the card.
Errors card Implementation:
We are adding all the errors as per screen name in an array and passing the erros as a props in ViewComposer component.
For draft status only:
| End point | Method | Payload |
|---|---|---|
/project-factory/v1/project-type/update
POST
{ "CampaignDetails": { "id": "eacb77b9-0bcd-4939-88a6-ca9456eb7bc4", "tenantId": "mz", "status": "drafted", "action": "create", "campaignNumber": "CMP-2024-05-09-001425", "campaignName": "checkte", "projectType": "LLIN-Moz", "hierarchyType": "ADMIN", "boundaryCode": "mz", "projectId": null, "startDate": 1715538599000, "endDate": 1717266599000, "additionalDetails": { "beneficiaryType": "HOUSEHOLD", "key": 10 }, "resources": [ { "type": "facility", "filename": "fac.xlsx", "filestoreId": "19be64bc-5a03-4932-9b88-90feb16e642a" }, { "type": "boundaryWithTarget", "filename": "TR.xlsx", "filestoreId": "8821993e-339b-4af5-9263-337276891065" } ], "boundaries": [ { "code": "mz", "type": "Country", "isRoot": true, "includeAllChildren": true }], "deliveryRules": [ { "startDate": 1715711399000, "endDate": 1716661799000, "cycleNumber": 1, "deliveryNumber": 1, "deliveryRuleNumber": 1, "products": [ { "value": "PVAR-2024-01-24-000076", "name": "SP - 500mg", "count": 1 } ], "conditions": [ { "attribute": "Age", "operator": "LESS_THAN", "value": 100 } ] } ], "auditDetails": { "createdBy": "63a21269-d40d-4c26-878f-4f4486b1f44b", "lastModifiedBy": "63a21269-d40d-4c26-878f-4f4486b1f44b", "createdTime": 1715275958664, "lastModifiedTime": 1715276207117 } }, "RequestInfo": { } }
The resource upload details consists of 3 types of uploads:
Upload Target Data
Facility Upload
User Upload
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.
This screen will come after the target upload screen.
In this screen, when a user clicks on the download template, an Excel get downloaded that contains 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.
This screen will appear after the facility Details screen.
When a user clicks on the download template, an Excel gets downloaded that consists of with readMe, User Sheet and BoundaryData. The user has to fill 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:
Next, /project-factory/v1/data/_download is used to download the template.
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-
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:
Before calling we are using base time out which is fetched from the MDMS
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-
Preview component: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/XlsPreview.js
A new popup has been added which display the option to download the template in all the 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.
This screen allows a user to select different boundary details required for the campaign creation. Here, we show the boundary types based on the hierarchy type which is present in the MDMS, MDMS file path :
If we want to fetch the hierarchy type from the MDMS, use the following API:
To fetch the hierarchy definition, this is mentioned in the setUpCampaign page:
After calling the hierarchy, the response is stored in the session storage under the name:
After it is stored, we can use it in the "Selecting Boundaries" component to show the different boundary types present: The FilePath for it is the following: The boundary type in the screen is shown upto the lowest hierarchy level which is also configured from the MDMS. The options in the hierarchy is shown using the following:
In the selection boundary screen, we show options according to parent boundary type using the above API. Some validations for this screen:
All the boundary types in the screen are mandatory.
Lower level boundary type is mandatory if a user has selected the above levels
We have impemented Parallel API calls have been implemented for boundary data search to optimise the performance better. We have added all the API search from the loop and calling parallel calls at once and storing the respective data in respective boundaryType.
For the next time when we are making boundary search api calls, we are checking locally whether data is present otherwise calling the API search only for the required data to optimise it better.
All the above mentioned logic have been added in useParallelSearch.js hook.
| End Point | Method | Payload |
|---|---|---|
After the boundaries are selected, the Generate API is called with a delay of 3 seconds when the user clicks on next, using the following hook:
Link:
| EndPoint | Method | Payload |
|---|
/project-factory/v1/data/_generate
POST
Params will be different for different types- 1) facilityWithBoundary
tenantId:mz
type:facilityWithBoundary
forceUpdate:true
hierarchyType:ADMIN
campaignId:13175791-db53-4d10-be90-2dba1c138756 2) boundary tenantId:mz
type:boundary
forceUpdate:true
hierarchyType:ADMIN
campaignId:13175791-db53-4d10-be90-2dba1c138756 3)userWithBoundary tenantId:mz
type:userWithBoundary
forceUpdate:true
hierarchyType:ADMIN
campaignId:13175791-db53-4d10-be90-2dba1c138756
/project-factory/v1/data/_download
POST
Params will be different for different types- 1)boundary tenantId:mz
type:boundary
hierarchyType:ADMIN
id:987eadc3-55a0-4553-925d-bf8087f57e5a 2)facilityWithBoundary tenantId:mz
type:facilityWithBoundary
hierarchyType:ADMIN
id:052f59fc-18a7-4e07-816a-f5d8062b56b5 3)userWithBoundary tenantId:mz
type:userWithBoundary
hierarchyType:ADMIN
id:fbfbd393-d053-4f51-9e12-1068b97da292
/project-factory/v1/data/_create
POST
1) type: boundaryWithTarget { "type": "boundaryWithTarget", "hierarchyType": "ADMIN", "tenantId": "mz", "fileStoreId": "ad9efbdb-b2c5-434e-b86e-1cb02d61e758", "action": "validate", "campaignId": "13175791-db53-4d10-be90-2dba1c138756", "additionalDetails": {} } 2) type: facility { "type": "facility", "hierarchyType": "ADMIN", "tenantId": "mz", "fileStoreId": "a5ca723c-e463-4428-86b4-e0f706973857", "action": "validate", "campaignId": "13175791-db53-4d10-be90-2dba1c138756", "additionalDetails": {} } 3) type: user { "type": "user", "hierarchyType": "ADMIN", "tenantId": "mz", "fileStoreId": "3f6348b0-7e10-4f1a-8f48-dcfb0c9afdff", "action": "validate", "campaignId": "13175791-db53-4d10-be90-2dba1c138756", "additionalDetails": {} }
boundary-service/boundary-relationships/_search | POST | Params tenantId=mz hierarchyType=ADMIN boundaryType=Provincia parent=ADMIN_MO |
/boundary-service/boundary-hierarchy-definition/_search | POST | { "tenantId": "mz", "limit": 2, "offset": 0, "hierarchyType": "ADMIN" } |
