Template dummy data for configure rules-

{
  "checklistConfig": [
    {
      "tabType": "referral",
      "rulesConfig": [
        {
          "ruleNumber": 1,
          "conditions": [
            {
              "code": "SN1",
              "values":
                "SHORTAGES"
              
            },
            {
              "condition": 2,
              "isRequired": true,
              "code": "SN2",
              "values": [
                "HOSPITALS",
              ]
            }
          ]
        },
        {
          "ruleNumber": 2,
          "conditions": [
            {
              "condition": 1,
              "isRequired": true,
              "code": "SN3",
              "values": [
                "YES"
              ]
            },
            {
              "condition": 2,
              "isRequired": true,
              "code": "SN4",
              "values": [
                "YES"
              ]
            }
          ]
        }
      ]
    }
  ]
}

Output data format

{
  "checklistConfig": [
    {
      "tabType": "referral",
      "rulesConfig": [
        {
          "ruleNumber": 1,
          "conditions": [
            {
              "id": "2d4a7b1e-1f2f-4a8a-9672-43396c6c9a1c",
              "condition": 1,
              "isRequired": true,
              "code": "Is the child administered for the first time?",
              "values": [
                "YES",
                "NO",
                "NOTSELECTED"
              ],
              "answer": [
                "YES"
              ]
            },
            {
              "id": "2d4a7b1e-1f2f-4a8a-9672-43396c6c9a1c",
              "condition": 1,
              "isRequired": true,
              "code": "Is the child administered for the second time?",
              "values": [
                "YES",
                "NO",
                "NOTSELECTED"
              ],
              "answer": [
                "NO"
              ]
            }
          ]
        },
        {
          "ruleNumber": 2,
          "conditions": [
            {
              "id": "2d4a7b1e-1f2f-4a8a-9672-43396c6c9a1c",
              "condition": 1,
              "isRequired": true,
              "code": "Is the child sick?",
              "values": [
                "YES",
                "NO",
                "NOTSELECTED"
              ],
              "answer": [
                "NO"
              ]
            }
          ]
        }
      ]
    },
    {
      "tabType": "delivery",
      "rulesConfig": [
        {
          "ruleNumber": 1,
          "conditions": [
            {
              "id": "4add5323-fc98-4e71-a783-27dbb922c99f",
              "condition": 2,
              "isRequired": true,
              "code": "Is the child having fever?",
              "values": [
                "YES",
                "NO",
                "NOTSELECTED"
              ],
              "answer": [
                "YES"
              ]
            }
          ]
        },
        {
          "ruleNumber": 2,
          "conditions": [
            {
              "id": "4add5323-fc98-4e71-a783-27dbb922c99f",
              "condition": 2,
              "parentId": null,
              "isRequired": true,
              "code": "Is child above 5 years?",
              "values": [
                "YES",
                "NO",
                "NOTSELECTED"
              ],
              "answer": [
                "YES"
              ]
            }
          ]
        }
      ]
    }
  ]
}

Points logic

This will be written in the wrapper For the points assignment for the questions, we will calculate on the basis of Screen Type and/or condition AND/OR Conditions Points assigned for each referral = 100

X = 100/ no of rules

Points for each ques = x/no of conditions in each rule

Limitations

If same ques is available for one than one referral flow, then point assigned to them will be equal for more than one flow, that will cause discrepancy in the app, Possible solutions to this

1) if the points are the same for a ques for more than one flow then , we can introduce a variable for flow preference in the app, if points are same then go with the flow preference.

2) Or we can put validation from the console side , that question cannot be repeated more than once

FLOW

Data required for the api This transform of data will happen in a wrapper

{
  "tenantId": "mz",
  "code": "SMC Campaign.ELIGIBILITY.DISTRIBUTOR",
  "isActive": true,
  "additionalFields": {
    "schema": "ServiceDefinition",
    "version": 1,
    "fields": [
      {
        "key": "precedenceFlow",
        "value": "SMC1.YES"
      },
      {
        "key": "flow",
        "value": [
          "TO_ADMINISTER",
          "BENEFICIARY_REFUSED",
          "BENEFICIARY_REFERRED"
        ]
      }
    ]
  },
  "attributes": [
    {
      "tenantId": "mz",
      "code": "Is the child administered for the first time?",
      "dataType": "SingleValueList",
      "values": [
        "YES",
        "NO",
        "NOTSELECTED"
      ],
      "isActive": true,
      "required": true,
      "order": 1,
      "additionalFields": {
        "schema": "ServiceAttribute",
        "version": 1,
        "fields": [
          {
            "key": "pointsMapping",
            "value": {
              "YES": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NO": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 50
              },
              "NOTSELECTED": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              }
            }
          }
        ]
      }
    },
    {
      "tenantId": "mz",
      "code": "Is the child sick?",
      "dataType": "SingleValueList",
      "values": [
        "YES",
        "NO"
      ],
      "isActive": true,
      "required": true,
      "order": 2,
      "additionalFields": {
        "schema": "ServiceAttribute",
        "version": 1,
        "fields": [
          {
            "key": "pointsMapping",
            "value": {
              "YES": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NO": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 50
              }
            }
          }
        ]
      }
    },
    {
      "tenantId": "mz",
      "code": "Is the child having fever?",
      "dataType": "SingleValueList",
      "values": [
        "YES",
        "NO",
        "NOTSELECTED"
      ],
      "isActive": true,
      "required": true,
      "order": 3,
      "additionalFields": {
        "schema": "ServiceAttribute",
        "version": 1,
        "fields": [
          {
            "key": "pointsMapping",
            "value": {
              "YES": {
                "TO_ADMINISTER": 50,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NO": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NOTSELECTED": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              }
            }
          }
        ]
      }
    },
    {
      "tenantId": "mz",
      "code": "Is child above 5 years?",
      "dataType": "SingleValueList",
      "values": [
        "YES",
        "NO",
        "NOTSELECTED"
      ],
      "isActive": true,
      "required": true,
      "order": 4,
      "additionalFields": {
        "schema": "ServiceAttribute",
        "version": 1,
        "fields": [
          {
            "key": "pointsMapping",
            "value": {
              "YES": {
                "TO_ADMINISTER": 50,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NO": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              },
              "NOTSELECTED": {
                "TO_ADMINISTER": 0,
                "BENEFICIARY_REFUSED": 0,
                "BENEFICIARY_REFERRED": 0
              }
            }
          }
        ]
      }
    }
  ]
}

Technical Documentation: Create Campaign Web Flow

Overview

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.

Actors and Participants

• 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.

Sequence Flow

1. Campaign Setup Initialization

• 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.

2. Fetch Master Data

• 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.

3. Fetch Boundary Information

• 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.

4. User Data Input

• 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".

5. Template Generation

• ProjectFactory: Automatically triggers the generation of templates for different resources, including:

  • Target templates

  • Facility templates

  • User templates

6. Template Download and Storage

• 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.

7. Data Validation

• 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.

8. Validation Outcome

• 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.

9. Final Campaign Creation

• 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".

10. Campaign Creation Outcome

• 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.

Error Handling

• 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.

Web Sequence Diagram

Conclusion

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.

Technical Documentation: Update Campaign Web Flow

Overview

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.

Actors and Participants

• 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.

Sequence Flow

1. Initiating Campaign Update

• 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.

2. Fetching Campaign Data

• 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.

3. Fetching Boundary Information

• 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.

4. User Data Input

• 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".

5. Template Generation

• ProjectFactory: Automatically triggers the generation of templates for different resources, including:

  • Target templates

  • Facility templates

  • User templates

6. Template Download and Storage

• 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.

7. Data Validation

• 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.

8. Validation Outcome

• 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.

9. Final Campaign Update

• 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".

10. Campaign Update Outcome

• 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.

Error Handling

• 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.

Web Sequence Diagram

Conclusion

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.

Technical Documentation: Checklist Management Web Flow

Overview

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.

Actors and Participants

• 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.

Sequence Flow

Checklist Viewing Flow

1. Access Checklist View UI

   • The user accesses the Checklist View UI after a campaign has been created.

2. 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.

3. Display Checklists

   • CurrentScreen displays the checklists received from ServiceRequestService to the User.

4. 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.

5. 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.

Checklist Creation Flow

1. 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.

2. 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.

3. Loading Default Checklist Questions

   • CurrentScreen checks if there is a template available for the checklist and loads default checklist questions.

4. 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.

5. 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.

6. 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.

7. 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.

Error Handling

• 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.

Web Sequence Diagram

Conclusion

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 outlines the UI design and configuration of screens and components for the application. It includes schema requirements, support for dynamic sections, and the necessary master data to facilitate data flow.

Key Points to Consider:

1. Schema Integration Based on Project Type

   • The UI design should incorporate schemas that vary depending on the selected project type.

   • Dynamic rendering of components and fields based on schema definitions.

2. Enable AddSection Functionality

   • Provide an option to dynamically add sections to the screen configuration.

   • Ensure sections can be personalized and managed efficiently.

3. Master Data Requirements The following master data sets are required to support the UI design and component configurations:

   • AppScreenConfigTemplate Predefined templates for application screen configurations based on project type.

   • AppScreenConfigPersonalized Personalized configurations for screens, tailored to specific user roles or preferences.

   • ComponentMetaDataMaster Metadata defining the components, such as type, properties, and behavior.

   • FieldTypeMaster Master data for supported field types, including their attributes (e.g., input, dropdown, date picker).

Master Data: AppScreenConfigTemplate

Schema Overview

The AppScreenConfigTemplate defines the configuration and structure of application screens. It supports dynamic field addition, sections, comments, and card-based layouts.

{
  // Array of screens for the application
  "screens": [
    {
      // Unique name for the screen
      "name": "screen1",
      // Parent category of the screen
      "parent": "Registration",
      // Screen headers and descriptions
      "headers": [
        {
          // Header label
          "label": "KJHSJKDHKJH",
          // Type of the header (e.g., header, info, description)
          "type": "header"
        },
        {
          "label": "KJHSJKDHKJH",
          "type": "info"
        },
        {
          "label": "KJHSJKDHKJH",
          "type": "description"
        }
      ],
      // Screen configuration settings
      "config": {
        // Allows adding fields dynamically to the screen
        "enableFieldAddition": true,
        // Allows adding sections dynamically to the screen
        "enableSectionAddition": true,
        // Enables commenting functionality on the screen
        "enableComment": true,
        // Specifies where fields can be added (e.g., body, header, footer)
        "allowFieldsAdditionAt": [
          "body"
        ],
        // Specifies where comments can be added
        "allowCommentsAdditionAt": [
          "body"
        ]
      },
      // Cards within the screen (UI components grouped into cards)
      "cards": [
        {
          // Card header text
          "header": "Header",
          // Card description text
          "description": "Desc",
          // Fields inside the card
          "fields": [
            {
              // Path for binding data in the field
              "jsonPath": "Screen heading",
              // Type of the field (e.g., text, dropdown)
              "type": "text",
              // Label for the field
              "label": "dzdzddadadad",
              // Specifies if the field is mandatory
              "required": true,
              // Indicates if the field is active
              "active": true,
              // Additional metadata for the field
              "metaData": {
                // Field is read-only
                "readOnly": true,
                // Field supports comments
                "isComment": true
              }
            },
            {
              "jsonPath": "Description",
              "type": "text",
              "label": "dzdzddadadad",
              "required": true,
              "active": true,
              "metaData": {
                "isComment": true
              }
            },
            {
              "jsonPath": "Description",
              "type": "text",
              "label": "Address Line 1",
              "required": true,
              "active": true,
              "metaData": {}
            },
            {
              // Unique ID for the field
              "id": "field2",
              // Field type is dropdown
              "type": "dropdown",
              // Label for the dropdown field
              "label": "Beneficiary Status",
              // Additional metadata for dropdown field
              "metaData": {
                // Field is mandatory
                "required": true,
                // Options available for the dropdown
                "options": [
                  {
                    // Label for the dropdown option
                    "label": "Beneficiary Absent",
                    // Value associated with the dropdown option
                    "value": "absent"
                  },
                  {
                    "label": "Delivery Successful",
                    "value": "successful"
                  }
                ]
              }
            }
          ]
        }
      ]
    },
    {
      // Placeholder for additional screen configurations
    }
  ]
}

UPDATE

```json
{
  "screens": [
    {
      "name": "HOUSEHOLD_LOCATION",
      "parent": "REGISTRATION",
      "headers": [
        {
          "jsonPath": "SCREEN_HEADING",
          "type": "header",
          "label": "SCREEN_HEADING_LABEL",
          "required": true,
          "active": true,
          "metaData": {
            "fieldType": "text"
          }
        },
        {
          "jsonPath": "DESCRIPTION",
          "type": "description",
          "label": "DESCRIPTION_LABEL",
          "required": true,
          "active": true,
          "metaData": {
            "fieldType": "text"
          }
        }
      ],
      "config": {
        "enableFieldAddition": true,
        "enableSectionAddition": true,
        "enableComment": true,
        "allowFieldsAdditionAt": [
          "body"
        ],
        "allowCommentsAdditionAt": [
          "body"
        ]
      },
      "cards": [
        {
          "header": "HEADER_CODE",
          "description": "DESCRIPTION_CODE",
          "fields": [
            {
              "jsonPath": "ADDRESS_LINE_1",
              "type": "text",
              "label": "ADDRESS_LINE_1_LABEL",
              "required": true,
              "active": true,
              "metaData": {}
            },
            {
              "jsonPath": "ADDRESS_LINE_2",
              "type": "text",
              "label": "ADDRESS_LINE_2_LABEL",
              "required": true,
              "active": true,
              "metaData": {}
            }
          ]
        }
      ]
    }
  ]
}
```

Output Data structure for App config

[
  {
    "name": "HouseholdLocation",
    "type": "page",
    "components": [
      {
        "title": "Household Location",
        "description": "Make sure the village name matches the one where you are today.",
        "order": 1,
        "attributes": [
          {
            "name": "administrationArea",
            "type": "field",
            "isEnabled": true,
            "attribute": "textField",
            "readOnly": true,
            "isRequired": false,
            "order": 1,
            "source": "DEFAULT"
          },
          {
            "name": "accuracy",
            "isEnabled": true,
            "readOnly": true,
            "attribute": "textField",
            "isRequired": true,
            "order": 2
          },
          {
            "name": "addressLine1",
            "isEnabled": true,
            "readOnly": false,
            "attribute": "textField",
            "isRequired": false,
            "validation": [
              {
                "pattern": "^\\d+$",
                "key": "onlyDigits",
                "errorMessage": "Digits only"
              }
            ],
            "order": 1
          },
          {
            "name": "postalCode",
            "isEnabled": true,
            "readOnly": false,
            "attribute": "textField",
            "isRequired": false,
            "order": 1
          },
          {
            "name": "TextField",
            "type": "additionalField",
            "label": "TextField",
            "attribute": "textField",
            "formDataType": "String",
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "keyboardType": "number",
            "validation": [
              {
                "pattern": "^\\d+$",
                "key": "onlyDigits",
                "errorMessage": "Digits only"
              }
            ],
            "order": 1
          },
          {
            "name": "SelectionBox",
            "type": "additionalField",
            "label": "SelectionBox",
            "attribute": "selectionbox",
            "formDataType": "List<String>",
            "menuItems": [
              "a",
              "b",
              "c",
              "d"
            ],
            "allowMultipleSelection": true,
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "order": 2
          },
          {
            "name": "dateForm",
            "type": "additionalField",
            "label": "dateForm",
            "attribute": "dateFormPicker",
            "formDataType": "DateTime",
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "order": 5
          },
          {
            "name": "DropDown",
            "type": "additionalField",
            "label": "DropDown",
            "attribute": "dropdown",
            "formDataType": "String",
            "menuItems": [
              "a",
              "b"
            ],
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "order": 3
          },
          {
            "name": "dobPicker",
            "type": "additionalField",
            "label": "dobPicker",
            "attribute": "dobPicker",
            "formDataType": "DateTime",
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "order": 4
          },
          {
            "name": "integerFormPicker",
            "type": "additionalField",
            "label": "integerFormPicker",
            "attribute": "integerFormPicker",
            "formDataType": "int",
            "initialValue": 0,
            "minimum": 0,
            "maximum": 10,
            "isEnabled": true,
            "readOnly": false,
            "isRequired": false,
            "order": 6
          }
        ]
      }
    ]
  }
]

Field Type Master Data

This provides the configuration and metadata for various input field types used in the application. Each field type is mapped to a specific appType and includes metadata such as data types, validation rules, and other properties.

{
  "fieldType": [
    {
      "type": "textInput",
      "appType": "textField",
      "metadata": {
        "formDataType": "String",
        "validation": [
          {
            "pattern": "^\\d+$",
            "key": "onlyDigits",
            "errorMessage": "Digits only"
          }
        ]
      }
    },
    {
      "type": "number",
      "appType": "textField",
      "metadata": {
        "formDataType": "String",
        "keyboardType": "number",
        "validation": [
          {
            "pattern": "^\\d+$",
            "key": "onlyDigits",
            "errorMessage": "Digits only"
          }
        ]
      }
    },
    {
      "type": "dropDown",
      "appType": "dropdown",
      "metadata": {
        "formDataType": "String",
      },
     "attributeToRename": {
        "from": "options", 
        "to": "menuItems" // Rename "options" to "menuItems" when restructuring
        "optionalFunction": null
      }
      "attributeToDelete": [],
      }
    {
      "type": "checkbox",
      "appType": "selectionbox",
      "metadata": {
        "formDataType": "List<String>",
        "allowMultipleSelection": true,
      },
      "fieldRenameMap": {
        "options": "menuItems" // Rename "options" to "menuItems" when restructuring
      }
    },
    {
      "type": "counter",
      "appType": "integerFormPicker",
      "metadata": {
        "formDataType": "int",
        "initialValue": 0,
        "minimum": 0,
        "maximum": 10
      }
    },
    {
      "type": "datePicker",
      "appType": "dobPicker",
      "metadata": {
        "formDataType": "DateTime"
      }
    },
    {
      "type": "dobPicker",
      "appType": "dateFormPicker",
      "metadata": {
        "formDataType": "DateTime"
      }
    }
  ]
}

Drawer Master Data

The Drawer Master Data defines the configuration for the list of fields to be displayed in the drawer. Each field includes a label for identification and a fieldType that determines the type of input control to be rendered in the UI.

{
  "drawerData": [
    {
      "label": "componentType",
      "fieldType": "dropdown",
      "defaultValue": false,
      "visibilityEnabledFor": []
    },
    {
      "label": "Mandatory",
      "fieldType": "toggle",
      "defaultValue": false,
      "visibilityEnabledFor": ["textField", "dropDown"]
    },
    {
      "label": "label",
      "fieldType": "toggle",
      "defaultValue": false,
      "visibilityEnabledFor": ["textField", "dropDown"]
    },
    {
      "label": "helpText",
      "fieldType": "toggle",
      "defaultValue": false,
      "visibilityEnabledFor":[]
    },
    {
      "label": "innerLabel",
      "fieldType": "toggle",
      "defaultValue": false,
      "visibilityEnabledFor": []
    }
  ]
}

Localisation Master data

{
  "LocalisationData": {
    "screen": "appScreenConfig"
    "LocalisationModule":"configure-app",
    "moduleVersion": "3",
    "minModuleVersion": "1",
    "fields": [
      {
        "fieldType": "dropdown",
        "localisableProperties": ["label", "options", "placeholder"]
      },
      {
        "fieldType": "toggle",
        "applicableFieldTypes": ["textField", "dropDown"]
      },
      {
        "fieldType": "toggle",
        "applicableFieldTypes": ["textField", "dropDown"]
      },
      {
        "fieldType": "toggle",
        "applicableFieldTypes": []
      }
    ]
  }
}

Overview of the Flow:

1. Fetching the App Configuration from MDMSv2:

   • Step Description: The app configuration master data is fetched from the MDMSv2 (Master Data Management System version 2). This data includes the settings, components, field types, and other configurations that dictate the structure and behavior of the app’s screens and components.

   • Flow Detail:

     • The data is fetched asynchronously via an API call to the MDMSv2.

     • Once the data is fetched, it is stored in the application’s global state using React’s useContext. This ensures the data is accessible across various components throughout the app.

     • The data might look like:

       • Screen configurations (e.g., component layout, form field types).

       • Master data for field types, component metadata, drawer configurations, etc.

   • Considerations:

     • Ensure that proper error handling is in place if the API call fails (e.g., retry logic or fallback UI).

     • The context should be memoized or optimized for performance if the app grows large.

2. User Interactions (Editing, Adding, Deleting Components):

• Step Description: Once the data is loaded and the UI is rendered based on the fetched configuration, users can interact with the UI by editing, adding, or deleting fields and components.

• Flow Detail:

  • Editing: Users can modify the existing field values or configurations. For example, changing field labels, modifying validation rules, or adjusting layout properties.

  • Adding: Users can add new components, fields, or sections to the form. The UI should dynamically update to accommodate new fields or components.

  • Deleting: Users can delete specific components, fields, or entire sections, and the UI should reflect these changes instantly.

  • The updates made by the user are stored in the local state (managed by React’s useState or within the useContext).

• Considerations:

  • The system must handle edge cases such as removing fields that are required or have dependencies.

  • Ensure that updates are validated locally before sending them back to MDMSv2, to prevent inconsistencies.

1. Restructuring Data for Web or Mobile Outputs:

   • Step Description: After the user makes changes, the data must be restructured based on the target platform (e.g., web or mobile). This restructuring ensures that the configuration is correctly formatted to match the specifications required by the platform.

   • Flow Detail:

     • Once the data is updated, it is transformed according to the specific platform’s output format. For example:

       • For web applications, the configuration might need to be structured in a way that fits the web component framework (e.g., React).

       • For mobile applications, it may need to follow mobile-specific guidelines (e.g., using mobile UI components or formats).

     • The restructuring process may involve:

       • Converting configuration fields to fit the layout constraints of mobile screens (e.g., adjusting padding, margins).

       • Changing input types or validations for mobile responsiveness.

       • Adapting field types and labels based on the platform (e.g., dropdowns might be replaced with modals on mobile).

   • Considerations:

     • This step may require conditional logic to determine which platform the configuration is being prepared for.

     • It’s crucial that no data is lost during the restructuring process, so careful testing is needed.

2. Updating MDMSv2 (Client Master Data Structure):

   • Step Description: After the changes are made and the data has been restructured for the appropriate platform, the final updated configuration needs to be sent back to MDMSv2. This update is stored as the ClientMasterData structure.

   • Flow Detail:

     • The modified data is packaged into a ClientMasterData structure, which conforms to the MDMSv2 schema.

     • An API call is made to send the updated data back to MDMSv2, where it is stored.

     • The ClientMasterData structure typically includes:

       • Updated configuration for screens, components, fields, and other UI elements.

       • Any changes to validation rules, field types, or component properties.

     • The system should notify the user once the update has been successfully pushed to MDMSv2, ideally with a confirmation message or toast notification.

   • Considerations:

     • Ensure data integrity is maintained during the update process.

     • The system should handle error scenarios (e.g., failed updates, validation errors) and provide appropriate feedback to users.

     • Implementing a versioning system for the configuration data could help manage updates and rollback scenarios, ensuring consistency over time.

Sequence Diagram

Flow Diagram

App Integration

Once the config is created, if it is directly for MDMS v2, we will enrich it with additional metadata and send it directly to MDMS v2.

If code generation is required based on the alternative approach, we will convert the config into code changes and push it to GitHub for app generation.