The purpose of this document is to provide a comprehensive guide to the various configuration options available in 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 different 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 guidance provided 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:
After creating the hierarchy we can upload boundary data in bulk using.
In this screen, the user needs to first select the hierarchy type and download its respective template.
The template will be downloaded containing boundary levels in the headers according to the hierarchy. The user needs to fill that template in a specific format. For the reference, a dummy template is attached.
All the boundaries are localised using the 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.
This schema contains different hierarchy types and there lowest hierarchy. On the basis of isActive we choose on which type of hierarchy the campaign will be created. This config defines the boundary hierarchy on which campaign can be created. All the boundary levels are coming according to the hierarchy configured. The lowest hierarchy will represent the lowest level hierarchy to be displayed. The boundary data is displayed according to this. SplitBoundariesOn will state on which level the hierarchy we will divide the target sheet to show different boundary data of that particular boundary type.
User can change the lowest hierarchy but it is advised to keep till the mentioned level because 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 which 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.
Employement Type - Can be changed from the enum.
All the headers are mandatory they can be adjusted according to the requirement, just 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 campaign type boundary target updated, any new target column can be introduced.
Sample data:
while introducing a new campaign/project type this target schema needs to be added for it.
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 timeline after certain interval of time.
Advised not to change the base time and max time to prevent delay in validation progress.
It defines two project types, "LLIN-mz" and "MR-DN," each with specific configurations for attribute management, delivery settings, and cycle configurations. The delivery settings include conditions based on attributes and specific product configurations to be used during the delivery cycles.
Project Types:
LLIN-mz:
Attributes and deliveries cannot be added or disabled.
Allows custom attributes.
Configured for 1 cycle and 1 delivery.
Delivery includes attributes and products with conditions based on attribute values.
MR-DN:
Attributes and deliveries can be added.
Allows custom attributes.
Configured for 3 cycles and 3 deliveries.
Each delivery includes conditions for different age ranges and associated product configurations.
Conditions specify whether delivery is direct or indirect.
Common Configurations:
Attribute Configurations: Define specific attributes with their types, values, and conditions.
Product Configurations: Define products to be delivered, including details like key, count, value, and name.
Cycle Configurations: Specify the number of cycles and deliveries within each project type.
Conditions: Differentiate between direct and indirect deliveries based on attribute values (e.g., age ranges).
Direct delivery is configured by default, and from the next, it is indirect delivery. This is the default configuration according to the WHO recommendations; a user can also modify the same.
The product variant ID should be configured in the MDMS according to the environment.
Mandatory to set product variant ID according to the environment.
This is used in delivery config 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 the info message in the UI and read the 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.
Given 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 which 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. 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 config is used when we 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 , and if the user wants to update the dates at the lower boundary levels then make the flag as true.
Project factory service has a dependency on Kafka, Postgres and Rediss.
Changes in the HELM -
Multiple tabs are generated according to the boundary type mentioned in this; a user can change them according to the requirement:
To generate a default password or a random password:
To test for the mobile number:
