UI configuration for the application
This page offers details of the DIGIT UI configuration required to enable it in any environment. Browse through the configuration details listed below:
eGov recommends CD/CI be set up before developing on top of DIGIT. This ensures that new modules can be developed and deployed in a streamlined way. DIGIT ships with CI as code as part of the DevOps repository. Run the CI installer to set up DIGIT CD/CI before developing it on DIGIT.
Step 1: Add entry in build-config.yaml file in the master branch of the forked repository. This will set up the job pipeline in Jenkins. Make sure to add the same config to the feature branch you are working on. Refer to build-config.yaml.
Add the below content for digit-ui.
Step 2: Go to the Jenkins build page, select "Job Builder" and click on "Build now". This will pull the config from build_config.yaml and identify all modules that need to be built.
Step 3: Go to your Jenkins build page once the build is done. The service will appear under the repository path in which it has been added, that is, if the service is added under frontend, it will show up in the frontend section as below,
To learn more about the build and deployment process, visit:
Step 1: Add an entry in the helm chart of the frontend directory in the master branch of the forked DIGIT-DevOps repository.
Step 2: Deploy-as-code/helm/charts/frontend/digit-ui
Step 1: Locate the following "deploy-as-code/helm/environments/unified-health-dev.yaml" in the DevOps repository of your organization.
Step 2: Add the below code block within the environment YAML file used to deploy the Works platform -
Copy
Step 3: Modify the development environment sample file as per requirements.
This section contains the configuration that applies globally to all UI modules. These need to be configured before the configuration of service-specific UI.
Steps to create a globalconfig.js file:
Create a config file (globalconfigs.js) with the below-mentioned config (refer to code below).
Configure all the images/logos required in the S3 and add links as footerBWLogoURL , footerLogoURL.
Mention the state tenant ID as stateTenantId.
If any User roles have to be made invalid add as invalidEmployeeRoles.
Then push this global config file into your S3 bucket as globalconfigs.js
Mention the globalconfig file URL in your Environment config.
Copy:
The S3 bucket has to be configured by the DevOps team, to store all the assets being used in the application like Logos, globalConfigs, etc.
Steps to create a new AWS Bucket -
Create a new AWS S3 Bucket
Update the Bucket Policy with the following content, to make the bucket public
Copy:
Update the Cross-Origin Resource Sharing (CORS) configuration with the following content
Copy:
To proxy the same bucket in any environment and make the necessary changes in the environment.yaml file located in the DevOps repository's configmaps under egov-config, follow the steps below:
Add the s3-assets-bucket: "pg-egov-assets"
Copy:
After adding the proxy in the environment file, restart the s3-proxy build in the environment with config enabled.
Project factory service has a dependency on Kafka, Postgres, and Redis.
Changes in the HELM -
Auto-generate user password:
1. Password Management
Auto-generate user password:
Enables the system to generate a random password for new users.
Set a default user password:
Specifies a default password to be used if auto-generation is disabled.
2. User Duplication Check
Skip user creation if a mobile number already exists:
Prevents the creation of duplicate users by checking existing mobile numbers.
3. Tab Naming for Readme and Sheets
Readme Tab Name:
Defines the sheet name to be used for the ReadMe tab.
Tab names for different data sheets:
Sets tab names for facilities, boundary data, and user lists in the HCM Admin Console.
Localization and Default Locale
Set default locale:
Defines the default locale as "en_IN" unless overridden in the Helm values.
Localization module:
Specifies the localization module used for HCM schemas.
5. Logging Configuration
Set application log level:
Determines the verbosity of logs, defaulting to "info."
Set maximum debug characters:
Limits the maximum length of debug logs to 500 characters unless overridden.
6. User Mapping
Enable mapping users via a common parent:
Allows users to be linked based on a shared parent hierarchy.
7. Automatic Retry Mechanism
Retry when specific HTTP errors occur:
Automatically retries operations if the "socket hang up" error occurs.
8. Localisation wait time in Boundary Creation
Localisation wait time in Boundary Creation
9. Localisation Chunk Size
Localisation Chunk Size
KAFKA_BROKER_HOST
egov-config
kafka-brokers
EGOV_MDMS_HOST
egov-service-host
egov-mdms-service
EGOV_MDMS_V2_HOST
egov-service-host
mdms-service-v2
EGOV_FILESTORE_SERVICE_HOST
egov-service-host
egov-filestore
EGOV_IDGEN_HOST
egov-service-host
egov-idgen
EGOV_FACILITY_HOST
egov-service-host
facility
EGOV_BOUNDARY_HOST
egov-service-host
boundary-service
EGOV_PROJECT_HOST
egov-service-host
health-project
EGOV_USER_HOST
egov-service-host
egov-user
EGOV_PRODUCT_HOST
egov-service-host
product
EGOV_HRMS_HOST
egov-service-host
health-hrms
EGOV_LOCALIZATION_HOST
egov-service-host
egov-localization
EGOV_HEALTH_INDIVIDUAL_HOST
egov-service-host
health-individual
EGOV_AUDIT_HOST
egov-service-host
audit-service
EGOV_PLAN_SERVICE_HOST
egov-service-host
plan-service
EGOV_CENSUS_HOST
egov-service-host
census-service
FILE_STORE_SERVICE_END_POINT
filestore/v1/files
EGOV_MDMS_V2_SEARCH_ENDPOINT
mdms-v2/v2/_search
EGOV_MDMS_V1_SEARCH_ENDPOINT
mdms-v2/v1/_search
EGOV_IDGEN_PATH
egov-idgen/id/_generate
EGOV_MDMS_SCHEMA_PATH
mdms-v2/schema/v1/_search
EGOV_BOUNDARY_RELATIONSHIP_SEARCHPATH
boundary-service/boundary-relationships/_search
EGOV_BOUNDARY_SERVICE_SEARCHPATH
boundary-service/boundary/_search
EGOV_BOUNDARY_HIERARCHY_SEARCHPATH
boundary-service/boundary-hierarchy-definition/_search
HEALTH_PROJECT_CREATE_PATH
health-project/v1/_create
EGOV_PROJECT_STAFF_CREATE_PATH
health-project/staff/v1/_create
EGOV_PROJECT_RESOURCE_CREATE_PATH
health-project/resource/v1/_create
EGOV_PROJECT_RESOURCE_FACILITY_PATH
health-project/facility/v1/_create
EGOV_USER_SEARCH_PATH
user/_search
EGOV_FACILITY_SEARCH_PATH
facility/v1/_search
EGOV_PRODUCT_VARIANT_SEARCH_PATH
product/variant/v1/_search
EGOV_BOUNDARY_ENTITY_SEARCHPATH
boundary-service/boundary/_search
EGOV_FACILITY_BULK_CREATE
facility/v1/bulk/_create
EGOV_HEALTH_INDIVIDUAL_SEARCH
health-individual/v1/_search
EGOV_PLAN_FACILITY_SEARCH
plan-service/plan/facility/_search
EGOV_PLAN_FACILITY_CONFIG_SEARCH
plan-service/config/_search
EGOV_CENSUS_SEARCH
census-service/_search
EGOV_PLAN_SEARCH
plan-service/plan/_search
KAFKA_SAVE_CAMPAIGN_DETAILS_TOPIC
save-campaign-details
KAFKA_UPDATE_CAMPAIGN_DETAILS_TOPIC
update-campaign-details
The configuration snippet provides the details required to set up and connect to a database, including environment-specific handling, credentials, schema information, and other related settings. Below is a structured breakdown:
Database Connection Information
DB_URL
health-db-url or db-url from egov-config
URL for connecting to the database. Uses health-db-url in the "health" namespace, else db-url.
DB_HOST
db-host from egov-config
Hostname or IP address of the database server.
DB_PORT
"5432"
Port number for database connection (default PostgreSQL port).
DB_NAME
db-name from egov-config
Name of the database being connected to.
DB_SCHEMA
Namespace value or "public"
Specifies the schema within the database. Defaults to "public" if no namespace is provided.
DB_USER
username from db secret
Database username used for authentication.
DB_PASSWORD
password from db secret
Database password for authentication.
Flyway Migration Information
FLYWAY_USER
flyway-username from db secret
User for running Flyway migrations.
FLYWAY_PASSWORD
flyway-password from db secret
Password for Flyway migration user.
FLYWAY_LOCATIONS
flyway-locations from egov-config
Directory or path for Flyway migration scripts.
SCHEMA_TABLE
schemaTable from initContainers.dbMigration
Table name for tracking Flyway migrations.
General Notes
ConfigMap and Secrets Integration: Sensitive data like DB_USER, DB_PASSWORD, and Flyway credentials are securely retrieved from Kubernetes secrets (db secret). Non-sensitive configurations like DB_HOST and DB_NAME are stored in ConfigMaps (egov-config).
Namespace-Specific Configuration: The DB_URL and DB_SCHEMA are tailored for specific namespaces. For example, the "health" namespace uses a dedicated health-db-url key and the namespace value for the schema.
Default Settings: Where applicable, defaults are provided. For instance, the schema defaults to "public" and the port defaults to 5432.
These configurations enhance the flexibility and usability of the Project Factory Service, ensuring smoother operations and better alignment with user needs.
The document is a guide to the various configuration options available in the HCM Console. Proper configuration is crucial for optimising performance, ensuring security, and customising the user experience to meet specific needs. This document is designed to help system administrators, developers, and end-users understand and implement these configurations effectively. To learn more about HCM Service/App Configuration, Click here.
This guide covers all aspects of application configuration, including global settings, module-specific options, and environment-specific adjustments. It addresses configuration methods such as through files, environment variables, and command-line arguments. Additionally, it includes advanced configuration topics like custom scripting, API integrations, and feature flag management.
The primary audience for this document includes:
System Administrators: Responsible for setting up and maintaining the application in various environments.
Developers: Need to understand configuration options for development, testing, and deployment.
End-Users: They may require guidance on configuring user-specific settings via the user interface.
The document is organised into the following sections:
Configuration Types: Detailed descriptions of global, module-specific, and environment-specific settings.
Configuration Methods: Instructions on how to apply configurations using different methods.
Common Configuration Options: Examples of frequently used settings, including database connections, authentication, logging, and UI adjustments.
Advanced Configurations: Information on extending the application's functionality through custom scripts, plugins, and integrations.
Best Practices: Recommendations for managing configurations securely and efficiently.
Troubleshooting: Solutions to common configuration problems and tips for debugging issues.
Appendices: Additional resources, including a glossary and references for further reading.
By following the instructions in this document, users can ensure that the application is configured correctly to meet their operational needs, enhancing both performance and user satisfaction.
This overview section sets the stage for the rest of the document by clearly outlining its purpose, scope, intended audience, and overall structure.
The Boundary serves as the primary master data for a campaign and can be configured using the screen provided below. To upload a boundary into the database, a hierarchy is required. If the necessary hierarchy is not available in the existing list, it can be created using the designated screen. Hierarchies of any level can be established.
An example of a hierarchy structure is as follows, with the hierarchy type set to ADMIN:
First, navigate to the MDMS data configuration page with moduleName = HCM-ADMIN-CONSOLE and masterName = HierarchySchema and configure the console and campaign as the hierarchy you want to have (Ex. HierarchyTest22)
Keep hierarchy, lowest level, and split boundaries on column same for console and campaign and name should be same as defined while creating hierarchy. (Example: Here we have AdministrativePost and Locality)
Now navigate to the boundary management page and continue with boundary creation.
After creating the hierarchy, you can download the template and add data to it.
In this screen, the user needs to download the template containing boundary levels in the headers according to the hierarchy. The user needs to fill that template in a specific format. A dummy template is attached for reference.
All the boundaries are localised to the below localisation module:
The system automatically generates a default localization for all boundary codes during the boundary data upload, using the same language/locale as specified at the time of upload.
The data provided above is based on the hierarchy created above. Any changes in the levels will change the headers respectively and data will have to be filled accordingly.
This schema contains different hierarchy types and their lowest hierarchy.
Based on isActive, choose which type of hierarchy the campaign will be created. This configuration defines the boundary hierarchy on which a campaign can be created. All the boundary levels are coming according to the hierarchy configured.
The lowestHierarchy will represent the lowest level hierarchy to be displayed in the boundary selection screen while creating a campaign.
The SplitBoundariesOn defines the hierarchy level for dividing the target sheet tabs.
The consolidateUsersAt the function is utilised during microplan integration, ensuring user sheets are populated -
Users can change the lowest hierarchy but it is advised to keep till the mentioned level because a lot of boundaries will increase the validations and the load on the server to load all the boundaries
Based on this schema, validations happen in Excel from both the UI and the backend for the different uploads; there is one schema with the title according to the uploaded type. If a user wants to change anything in the Excel validation, then the data of the schema needs to be updated.
Schema properties:
IsRequired: True for all those columns that are mandatory to be filled
orderNumber: Position where that column will be present
title: Set according to the type of upload
enum: Defines a set of allowed values for a specific property, ensuring that only predefined, valid options can be assigned to that property.
numberProperties: Numeric fields with specific characteristics such as uniqueness, required status, and value constraints like minimum and maximum limits.
string properties: Text fields with specific characteristics such as required status, uniqueness, and constraints on length and content.
Users can change the following validations from Excel using this schema such as:
User Validations -
Roles - Roles to be validated can be added or deleted in the schema.
Employment Type - This can be changed from the enum.
All the headers are mandatory they can be adjusted according to the requirement by changing isRequired to true/false.
Facility Validations -
Facility Type - More types can be added or deleted.
Facility Status - More requirements can be added or deleted.
Facility Usage - More requirements can be added or deleted.
Capacity - Minimum and maximum can be changed.
Facility Name - Maximum length and minimum length can be changed.
All the headers are mandatory they can be adjusted according to the requirement, just by changing isRequired to true/false.
Target Validation -
Target - Minimum and maximum validations can be changed.
Boundary code and target header are mandatory.
It also has a field called campaign type, so based on the campaign type boundary target updated, any new target column can be introduced.
while introducing a new campaign/project type this admin schema needs to be added for that type.
It includes a list of attribute configurations, each identified by a unique key and specified by a code and an internationalisation key (i18nKey). The attributes listed are 'Age', 'Height', 'Weight', and 'Gender', which can be used in campaigns to capture relevant information.
The attribute dropdown is populated from this schema. If the user wants to add or delete attribute options, this schema is helpful.
This schema configures the base time interval after which the search API is called following a file upload. The search API checks the validation status of the uploaded file. The frequency of the API calls is determined by the data present, with the time interval calculated as the base time multiplied by the number of fields in the sheet, constrained by both the minimum base time and the maxTime stated in the schema. The search API will continue to be called repeatedly until a successful or failed response is received. TimelineRefetch is also added to call the getProcessAPI of the timeline after a certain interval of time.
Advised not to change the base time and max time to prevent delay in validation progress.
This is used in the delivery configuration schema to show the direct and indirect deliveries.
It has the by default mail ID to contact the L1 or implementation team if the hierarchy a user wants is not present. The mail ID can be configured from this schema -
This schema contains all the operator options which are required for the attributes.
This schema displays the options to add the resource type if the resource a user wants is not present in the options. The resource added here will be present in the resources dropdown, so prevent adding any junk data.
This schema is used to display the info message in the UI and the read-me sheet in the downloaded template. It configures according to the upload type which shows the instructions to a user on how to fill the template. These codes are localised according to the message.
Below is an example of how data is entered into the read-me schema for the headers and their description:
type: defined the type of upload.
header: The text identifier for the header.
isHeaderBold: A boolean indicating whether the header text should be displayed in bold.
inSheet: A boolean indicating whether this header should be included in the sheet.
inUiInfo: A boolean indicating whether this header should be displayed in the UI.
text: The text identifier for the description.
isStepRequired: A boolean indicating whether this description step is required.
All the headers and descriptions are written in codes that are localised using the localisation module named:
To show the privacy policy component on the login page, a user needs to include the configurations in the MDMS:
Master Name: commonUiConfig
ModuleName: LoginConfig
In this user can customize(add/delete) the fields according to the requirement.
For more details, you can refer here.
This configuration displays the data in the privacy pop-up. An example of the configuration is shown below:
In the schema:
Type can be the following:
null:
When type is null, it indicates that the description is just plain text.
point:
When type is set to point, it likely means that the description should be displayed as a bullet point or list item.
step:
When type is set to step, it suggests that the description is part of a sequence of steps.
subdescriptions: to show the sub-descriptions in the point.
This configuration is used when you want to update the dates with or without the selected boundaries.
If the flag is false, then by default it updates the dates at the country level. If you want to update the dates at the lower boundary levels, then make the flag true.
This configuration is now used in the place of delivery configuration.
This is used to store all the pre-required conditions for the delivery conditions screens.
Master Name: HCM-PROJECT-TYPES
ModuleName: projectTypes
This is the sample data for the project type - MR-DN
Explanation for the MDMS Data -
Project Types: Three main project types (LLIN-mz, MR-DN, and IRS-mz) with unique configurations.
Cycles and Deliveries:
Each project type contains cycles, and each cycle contains multiple deliveries.
Deliveries include details such as deliveryStrategy, doseCriteria, and ProductVariants.
Resources: A list of resources specific to each project type.
Eligibility Criteria: Contains a list of conditions for each project type.
Other Configurations:
attrAddDisable, deliveryAddDisable, and similar attributes determine UI behavior.
Requirements:
Mandatory to set product variant ID according to the environment.
This master data is used to show the dropdown of roles in the checklist screens -
This master data is used to default template of the checklist for selected campaign + role + checklist type -
This is used to describe the type of questions available in the dropdown while configuring the checklist.
This schema is used by replacing hierarchyConfig schema.
The Console is being referred to for campaign creation. The campaign is being referred for boundary management.
Here, we have 4 types which are being used in the campaign flow:
"type": "console": Used for the Campaign creation flow.
"type": "microplan": Used for the Microplan creation flow.
"type": "campaign": Used for the Boundary Management creation flow.
"type": "default": Serves as the default hierarchy for Boundary Management creation flow and holds default settings.
We support the development and handling of various use cases. However, we recommend using the same hierarchy configuration across all types to ensure a seamless flow. This allows for creating a microplan within the same hierarchy, building campaigns on it, and managing the boundary hierarchy consistently.
This master is utilised for the microplan data fetching. Here, 'type' refers to the data template that needs to be filled. 'To' and 'from' pertain to the microplan data, and while populating campaign data, various filter conditions, such as 'includes', or 'equals', can be applied.
To enable the generation of unique identifiers via idGen service, the following data must be added to the MDMS under moduleName=common-masters and masterName=IdFormat.
Ensure both configurations are added to MDMS before proceeding with ID generation.
HierarchySchema hierarchy schema is used now.
It was replaced by projectTypes to maintain the consistency between the health product app and console.
Refer here to learn more about the helm configurations
