Localization and Schem for release kit #133
Conversation
Satya-egov
requested review from
sathishp-eGov
and removed request for
a team
WalkthroughThe pull request introduces multiple new JSON configuration files for the HCM Admin Console, encompassing service configurations, role actions, hierarchical schemas, user and facility management schemas, timeout settings, email configurations, and privacy policies. Each file contains structured data to facilitate various functionalities, such as managing user roles, defining application field types, and configuring UI elements for the login interface. The changes enhance the organization and management of data within the application, ensuring clear definitions and validation rules for different entities. Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Outside diff range and nitpick comments (5)
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/commonUiCofig/LoginConfig.json (3)
2-7: Consider using consistent casing for the title fieldWhile the translation keys follow a consistent uppercase pattern (e.g., "CORE_COMMON_LOGIN"), the title field uses lowercase ("login"). Consider using a consistent casing pattern across all configuration fields.
- "title": "login", + "title": "LOGIN",
43-48: Security and Performance Concerns in MDMS Configuration
- The inline JavaScript in the select field poses potential security risks and makes maintenance difficult.
- Consider implementing caching for tenant data to improve performance.
Consider:
- Moving the transformation logic to a separate utility function
- Implementing tenant data caching with appropriate invalidation strategy
- Using a predefined selector pattern instead of inline JavaScript
"mdmsConfig": { - "select": "(data)=>{ return Array.isArray(data['tenant'].tenants) && Digit.Utils.getUnique(data['tenant'].tenants).map(ele=>({code:ele.code,name:Digit.Utils.locale.getTransformedLocale('TENANT_TENANTS_'+ele.code)}))}", + "select": "tenant.transformTenantList", "masterName": "tenants", "moduleName": "tenant", - "localePrefix": "TENANT_TENANTS" + "localePrefix": "TENANT_TENANTS", + "cache": { + "ttl": 3600, + "strategy": "stale-while-revalidate" + }
53-66: Enhance Privacy Component Documentation and AccessibilityThe privacy component configuration lacks:
- Documentation about its purpose and behavior
- Accessibility attributes
- Validation for the module value
{ "key": "check", "type": "component", "disable": false, "component": "PrivacyComponent", + "description": "Privacy policy acceptance checkbox component", + "aria-label": "Privacy Policy Agreement", "populators": { "name": "check" }, "customProps": { - "module": "HCM" + "module": "HCM", + "validation": { + "allowedModules": ["HCM", "HRMS"] + } }, "isMandatory": false, - "withoutLabel": true + "withoutLabel": true, + "accessibilityProps": { + "role": "checkbox", + "tabIndex": 0 + } }mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/adminSchema.json (2)
31-38: Improve email and name validation patternsThe current validation for email and name fields is insufficient:
- Email pattern could allow invalid addresses
- Name validation only checks length without character restrictions
Enhance the validation patterns:
{ "name": "HCM_ADMIN_CONSOLE_USER_EMAIL_MICROPLAN", "type": "string", - "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", + "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$", "maxLength": 128, "minLength": 2, "isRequired": false } { "name": "HCM_ADMIN_CONSOLE_USER_NAME", "type": "string", + "pattern": "^[a-zA-Z]+(([',. -][a-zA-Z ])?[a-zA-Z]*)*$", "maxLength": 128, "minLength": 2, "isRequired": true }Also applies to: 1182-1190
1169-1180: Add international phone number validationThe phone number validation is too restrictive and doesn't support international formats.
Update the phone number validation to support international formats:
{ "name": "HCM_ADMIN_CONSOLE_USER_PHONE_NUMBER", "type": "number", - "maximum": 9999999999, - "minimum": 1000000000, + "type": "string", + "pattern": "^\\+?[1-9]\\d{1,14}$", "isUnique": true, "isRequired": true, "description": "Phone Number (International format)", "orderNumber": 2, "errorMessage": "Please enter a valid international phone number" }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (16)
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/Core/A.action-test.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/Core/A.roleactions.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/HierarchySchema.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/adminSchema.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/appFieldTypes.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/attributeConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/baseTimeOut.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/hierarchyConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/mailConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/microplanIntegration.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/operatorConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/productType.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/readMeConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/rolesForChecklist.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/commonUiCofig/LoginConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/commonUiCofig/PrivacyPolicy.json(1 hunks)
✅ Files skipped from review due to trivial changes (8)
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/mailConfig.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/appFieldTypes.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/baseTimeOut.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/rolesForChecklist.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/operatorConfig.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/productType.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/hierarchyConfig.json
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/commonUiCofig/PrivacyPolicy.json
🔇 Additional comments (6)
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/attributeConfig.json (2)
3-6: Review key assignment strategy
The key values (4 for Gender, 1 for Age) appear to be non-sequential. This might indicate:
- Missing attributes (keys 2,3 are not used)
- Inconsistent key assignment strategy
Let's check if there are any related configuration files that might explain the key assignment:
Also applies to: 8-11
✅ Verification successful
Non-sequential keys are intentional - attributes were removed from v0.1 to v0.3
The key assignment strategy is actually consistent. Comparing v0.1 and v0.3 of attributeConfig.json shows that keys 2 (Height) and 3 (Weight) were present in v0.1 but were intentionally removed in v0.3, while maintaining the original key values for Age (1) and Gender (4) to preserve referential integrity.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other configuration files that might reference these keys
rg -l "key.*[14].*Gender|Age" --type json
Length of output: 3999
Script:
#!/bin/bash
# Let's check the content of attributeConfig.json in both v0.1 and v0.3 to see the key assignments
echo "=== v0.1 attributeConfig.json ==="
cat "mdms/HCM/HCM ADMINCONSOLE v0.1/JSON DATAS/HCM Admin Console/attributeConfig.json"
echo -e "\n=== v0.3 attributeConfig.json ==="
cat "mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/attributeConfig.json"
Length of output: 975
5-5: Verify i18n key existence
Ensure that the internationalization keys "CAMPAIGN_ATTRIBUTE_GENDER" and "CAMPAIGN_ATTRIBUTE_AGE" are defined in the localization files.
Also applies to: 10-10
✅ Verification successful
Let me verify the actual content of these i18n keys in the localization files to ensure they are properly defined.
Let me try with the correct path pattern since there might be spaces in the directory names.
Let me check the complete entries to ensure these keys have associated translations.
Let me try one more time with the exact file paths to check the translations.
i18n keys are properly defined and translated
Both "CAMPAIGN_ATTRIBUTE_GENDER" and "CAMPAIGN_ATTRIBUTE_AGE" keys are properly defined in the localization files with appropriate translations. The keys are present in English, French, and Portuguese localization files with meaningful messages:
- CAMPAIGN_ATTRIBUTE_GENDER: "Gender (Male or Female)"
- CAMPAIGN_ATTRIBUTE_AGE: "Age (in months)"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the i18n keys in localization files
rg -l "CAMPAIGN_ATTRIBUTE_(GENDER|AGE)" --type json
Length of output: 811
Script:
#!/bin/bash
# Check the content of i18n keys in the latest version (v0.3) localization files
rg "CAMPAIGN_ATTRIBUTE_(GENDER|AGE)" "localisation/HCM Admin Console/v0.3/*/hcm-campaignmanager.json"
Length of output: 206
Script:
#!/bin/bash
# Check the content of i18n keys in the latest version localization files
rg "CAMPAIGN_ATTRIBUTE_(GENDER|AGE)" "localisation/HCM Admin Console/consolidated/en_MZ/rainmaker-campaignmanager.json" "localisation/HCM Admin Console/consolidated/fr_MZ/rainmaker-campaignmanager.json" "localisation/HCM Admin Console/consolidated/pt_MZ/rainmaker-campaignmanager.json"
Length of output: 1034
Script:
#!/bin/bash
# Get the complete entries including the translations
rg -A 2 "\"code\": \"CAMPAIGN_ATTRIBUTE_(GENDER|AGE)\"" "localisation/HCM Admin Console/consolidated/*/rainmaker-campaignmanager.json"
Length of output: 249
Script:
#!/bin/bash
# Get the complete entries including the translations
rg -A 2 "\"code\": \"CAMPAIGN_ATTRIBUTE_(GENDER|AGE)\"" "localisation/HCM Admin Console/consolidated/en_MZ/rainmaker-campaignmanager.json"
Length of output: 404
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/commonUiCofig/LoginConfig.json (1)
1-68: Verify translation keys and error handling
Please ensure that:
- All translation keys (CORE_, ERR_) exist in the localization files
- Error handling is consistent across all input fields
✅ Verification successful
Based on the search results, I can see that all the translation keys used in the LoginConfig.json file exist in various localization files across the codebase. The error keys also follow a consistent pattern with other error keys in the system. Let me break down the findings:
Translation keys verified:
- CORE_COMMON_LOGIN
- CORE_COMMON_CONTINUE
- CORE_COMMON_FORGOT_PASSWORD
- CORE_LOGIN_USERNAME
- CORE_LOGIN_PASSWORD
- CORE_COMMON_CITY
Error keys verified:
- ERR_USERNAME_REQUIRED
- ERR_PASSWORD_REQUIRED
- ERR_HRMS_INVALID_CITY
All keys are present in multiple localization files including:
- localisation/HCM/consolidated/en_MZ/consolidated.json
- localisation/HCM/consolidated/pt_MZ/consolidated.json
- localisation/HCM/V1.5/en_MZ/hcm-common.json
- And many others
The error handling is also consistent with the application's error handling pattern, where all error keys follow the "ERR_" prefix convention.
Translation keys and error handling are properly configured
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if all translation keys exist in localization files
echo "Checking translation keys..."
rg -l "CORE_COMMON_LOGIN|CORE_COMMON_CONTINUE|CORE_COMMON_FORGOT_PASSWORD|CORE_LOGIN_USERNAME|CORE_LOGIN_PASSWORD|CORE_COMMON_CITY|ERR_USERNAME_REQUIRED|ERR_PASSWORD_REQUIRED|ERR_HRMS_INVALID_CITY" --type json
# Check for consistent error key patterns
echo "Checking error key patterns..."
rg "ERR_" --type json -A 1 -B 1
Length of output: 100069
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/Core/A.roleactions.json (1)
1-20: Add documentation and validate empty actioncode field
- The empty
actioncodefield in all entries might cause issues if it's a required field. Please verify if this is intentional. - Consider adding comments or documentation to explain what each action ID represents:
- 2030: Project Type progress track
- 2031: HEALTH PROJECT SEARCH
- 2032: Health Project Update
✅ Verification successful
Based on the extensive output showing role actions from previous versions, I can now provide a definitive response:
Empty actioncode field is standard practice
The empty actioncode field in the CAMPAIGN_MANAGER role actions follows the established pattern across the codebase, where all role-action mappings consistently use an empty string for the actioncode field. This is not an issue but rather the standard configuration format.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if actioncode is required by searching for other roleactions files
fd -e json -x grep -l "actioncode" {}
Length of output: 289
Script:
#!/bin/bash
# Check the schema definition and other roleactions files to understand the actioncode field usage
cat ./mdms/HCM/HCM\ ADMINCONSOLE\ v0.1/schemas.json | jq '.definitions.RoleAction'
# Check other roleactions files for patterns
cat ./mdms/HCM/HCM\ ADMINCONSOLE\ v0.{1,2}/JSON\ DATAS/Core/A.roleactions.json | jq -c '.[]' | grep actioncode
Length of output: 65832
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/Core/A.action-test.json (1)
3-11: Review service configuration for project-factory
The service configuration uses a different serviceCode ("project-factory") compared to other entries ("project"). Please verify if this distinction is intentional.
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/HierarchySchema.json (1)
1-54: 🛠️ Refactor suggestion
Standardize language usage in hierarchy levels
The hierarchy levels use mixed languages:
- English: "VILLAGE", "COUNTRY", "DISTRICT", "ADMINISTRATIVEPOST"
- Portuguese: "Posto Administrativo", "Provincia"
Choose one language (preferably English) and standardize all hierarchy levels accordingly:
- "lowestHierarchy": "Posto Administrativo",
- "splitBoundariesOn": "Provincia"
+ "lowestHierarchy": "ADMINISTRATIVE_POST",
+ "splitBoundariesOn": "PROVINCE"| [ | ||
| { | ||
| "key": 4, | ||
| "code": "Gender", | ||
| "i18nKey": "CAMPAIGN_ATTRIBUTE_GENDER" | ||
| }, | ||
| { | ||
| "key": 1, | ||
| "code": "Age", | ||
| "i18nKey": "CAMPAIGN_ATTRIBUTE_AGE" | ||
| } | ||
| ] |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding schema validation and type information
The attribute configuration would benefit from additional metadata to ensure data integrity:
- Add type information (e.g., string, number, enum)
- Define validation constraints (e.g., allowed values for Gender, age ranges)
- Include descriptions for each attribute
Consider enhancing the structure like this:
[
{
"key": 4,
"code": "Gender",
- "i18nKey": "CAMPAIGN_ATTRIBUTE_GENDER"
+ "i18nKey": "CAMPAIGN_ATTRIBUTE_GENDER",
+ "type": "enum",
+ "allowedValues": ["MALE", "FEMALE", "OTHER"],
+ "description": "Gender of the campaign target audience",
+ "required": true
},
{
"key": 1,
"code": "Age",
- "i18nKey": "CAMPAIGN_ATTRIBUTE_AGE"
+ "i18nKey": "CAMPAIGN_ATTRIBUTE_AGE",
+ "type": "number",
+ "validation": {
+ "min": 0,
+ "max": 120
+ },
+ "description": "Age of the campaign target audience",
+ "required": true
}
]Committable suggestion skipped: line range outside the PR's diff.
| { | ||
| "key": "username", | ||
| "type": "text", | ||
| "label": "CORE_LOGIN_USERNAME", | ||
| "populators": { | ||
| "name": "username", | ||
| "error": "ERR_USERNAME_REQUIRED", | ||
| "validation": { | ||
| "required": true | ||
| } | ||
| }, | ||
| "isMandatory": true | ||
| }, |
There was a problem hiding this comment.
Enhance username field validation
The current validation only checks if the field is not empty. Consider adding:
- Maximum length restriction
- Character pattern validation
- Input sanitization rules
"validation": {
- "required": true
+ "required": true,
+ "pattern": "^[a-zA-Z0-9_@.]{3,50}$",
+ "maxLength": 50
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "key": "username", | |
| "type": "text", | |
| "label": "CORE_LOGIN_USERNAME", | |
| "populators": { | |
| "name": "username", | |
| "error": "ERR_USERNAME_REQUIRED", | |
| "validation": { | |
| "required": true | |
| } | |
| }, | |
| "isMandatory": true | |
| }, | |
| { | |
| "key": "username", | |
| "type": "text", | |
| "label": "CORE_LOGIN_USERNAME", | |
| "populators": { | |
| "name": "username", | |
| "error": "ERR_USERNAME_REQUIRED", | |
| "validation": { | |
| "required": true, | |
| "pattern": "^[a-zA-Z0-9_@.]{3,50}$", | |
| "maxLength": 50 | |
| } | |
| }, | |
| "isMandatory": true | |
| }, |
| { | ||
| "key": "password", | ||
| "type": "password", | ||
| "label": "CORE_LOGIN_PASSWORD", | ||
| "populators": { | ||
| "name": "password", | ||
| "error": "ERR_PASSWORD_REQUIRED", | ||
| "validation": { | ||
| "required": true | ||
| } | ||
| }, | ||
| "isMandatory": true | ||
| }, |
There was a problem hiding this comment.
Add password complexity requirements
The password field lacks security validations. Consider adding:
- Minimum length requirement
- Complex password pattern (uppercase, lowercase, numbers, special characters)
- Custom error messages for each validation rule
"validation": {
- "required": true
+ "required": true,
+ "pattern": "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*?&])[A-Za-z\\d@$!%*?&]{8,}$",
+ "minLength": 8,
+ "maxLength": 128
},
+ "customValidationMessages": {
+ "pattern": "ERR_PASSWORD_COMPLEXITY",
+ "minLength": "ERR_PASSWORD_MIN_LENGTH",
+ "maxLength": "ERR_PASSWORD_MAX_LENGTH"
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "key": "password", | |
| "type": "password", | |
| "label": "CORE_LOGIN_PASSWORD", | |
| "populators": { | |
| "name": "password", | |
| "error": "ERR_PASSWORD_REQUIRED", | |
| "validation": { | |
| "required": true | |
| } | |
| }, | |
| "isMandatory": true | |
| }, | |
| { | |
| "key": "password", | |
| "type": "password", | |
| "label": "CORE_LOGIN_PASSWORD", | |
| "populators": { | |
| "name": "password", | |
| "error": "ERR_PASSWORD_REQUIRED", | |
| "validation": { | |
| "required": true, | |
| "pattern": "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*?&])[A-Za-z\\d@$!%*?&]{8,}$", | |
| "minLength": 8, | |
| "maxLength": 128 | |
| }, | |
| "customValidationMessages": { | |
| "pattern": "ERR_PASSWORD_COMPLEXITY", | |
| "minLength": "ERR_PASSWORD_MIN_LENGTH", | |
| "maxLength": "ERR_PASSWORD_MAX_LENGTH" | |
| } | |
| }, | |
| "isMandatory": true | |
| }, |
| [ | ||
| { | ||
| "id": 2030, | ||
| "url": "/project-factory/v1/project-type/getProcessTrack", | ||
| "name": "Project Type progress track", | ||
| "enabled": true, | ||
| "leftIcon": "dynamic:ContractIcon", | ||
| "displayName": "Project Type progress track", | ||
| "orderNumber": -1, | ||
| "serviceCode": "project-factory" | ||
| }, | ||
|
|
||
| { | ||
| "id": 2031, | ||
| "url": "/health-project/v1/_search", | ||
| "name": "HEALTH PROJECT SEARCH", | ||
| "enabled": true, | ||
| "leftIcon": "dynamic:ContractIcon", | ||
| "displayName": "HEALTH PROJECT SEARCH", | ||
| "orderNumber": 0, | ||
| "serviceCode": "project" | ||
| }, | ||
|
|
||
| { | ||
| "id": 2032, | ||
| "url": "/health-project/v1/_update", | ||
| "name": "Health Project Update", | ||
| "enabled": true, | ||
| "leftIcon": "dynamic:ContractIcon", | ||
| "displayName": "Health Project Update", | ||
| "orderNumber": 0, | ||
| "serviceCode": "project" | ||
| } | ||
| ] |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Standardize naming conventions and configuration
-
Inconsistent naming conventions across services:
- "Project Type progress track" (Title case)
- "HEALTH PROJECT SEARCH" (Upper case)
- "Health Project Update" (Title case)
-
Inconsistent
orderNumbervalues (-1 vs 0) without clear reasoning
Consider standardizing:
- "name": "Project Type progress track",
+ "name": "PROJECT TYPE PROGRESS TRACK",
...
- "orderNumber": -1,
+ "orderNumber": 0,Committable suggestion skipped: line range outside the PR's diff.
| { | ||
| "type": "microplan", | ||
| "group": [ | ||
| "MALARIA" | ||
| ], | ||
| "hierarchy": "MICROPLAN", | ||
| "department": [], | ||
| "lowestHierarchy": "VILLAGE", | ||
| "highestHierarchy": "COUNTRY", | ||
| "splitBoundariesOn": "DISTRICT" | ||
| }, | ||
| { | ||
| "type": "microplan", | ||
| "group": [ | ||
| "MALARIA" | ||
| ], | ||
| "hierarchy": "MICROPLAN", | ||
| "department": [], | ||
| "lowestHierarchy": "VILLAGE", | ||
| "highestHierarchy": "COUNTRY", | ||
| "splitBoundariesOn": "DISTRICT" | ||
| }, |
There was a problem hiding this comment.
Remove duplicate microplan configuration
The file contains two identical microplan configurations. This duplication should be removed to prevent maintenance issues.
Remove the duplicate entry (lines 13-23).
| "type": "default", | ||
| "group": [ | ||
| "MALARIA" | ||
| ], | ||
| "hierarchy": "DEFAULTBOUNDARYNEWONE", | ||
| "department": [], | ||
| "lowestlevel": "ADMINISTRATIVEPOST", | ||
| "splitBasedOn": "DISTRICT" | ||
| }, |
There was a problem hiding this comment.
Standardize property names and add missing fields
The "default" type configuration uses inconsistent property names:
lowestlevelinstead oflowestHierarchysplitBasedOninstead ofsplitBoundariesOn- Missing
highestHierarchyfield
Apply this standardization:
"type": "default",
"group": ["MALARIA"],
"hierarchy": "DEFAULTBOUNDARYNEWONE",
"department": [],
- "lowestlevel": "ADMINISTRATIVEPOST",
- "splitBasedOn": "DISTRICT"
+ "lowestHierarchy": "ADMINISTRATIVEPOST",
+ "highestHierarchy": "COUNTRY",
+ "splitBoundariesOn": "DISTRICT"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "type": "default", | |
| "group": [ | |
| "MALARIA" | |
| ], | |
| "hierarchy": "DEFAULTBOUNDARYNEWONE", | |
| "department": [], | |
| "lowestlevel": "ADMINISTRATIVEPOST", | |
| "splitBasedOn": "DISTRICT" | |
| }, | |
| "type": "default", | |
| "group": [ | |
| "MALARIA" | |
| ], | |
| "hierarchy": "DEFAULTBOUNDARYNEWONE", | |
| "department": [], | |
| "lowestHierarchy": "ADMINISTRATIVEPOST", | |
| "highestHierarchy": "COUNTRY", | |
| "splitBoundariesOn": "DISTRICT" | |
| }, |
| [ | ||
| { | ||
| "type": "user", | ||
| "mappings": [ | ||
| { | ||
| "to": "Supervisor", | ||
| "from": [ | ||
| "PER_BOUNDARY_FOR_THE_CAMPAIGN", | ||
| "PER_BOUNDARY", | ||
| "TEAM", | ||
| "SUPERVISORS" | ||
| ], | ||
| "filter": "includes" | ||
| }, | ||
| { | ||
| "to": "Registrar", | ||
| "from": [ | ||
| "PER_BOUNDARY_FOR_THE_CAMPAIGN", | ||
| "PER_BOUNDARY", | ||
| "TEAM", | ||
| "REGISTRATION" | ||
| ], | ||
| "filter": "includes" | ||
| }, | ||
| { | ||
| "to": "Distributor", | ||
| "from": [ | ||
| "PER_BOUNDARY_FOR_THE_CAMPAIGN", | ||
| "PER_BOUNDARY", | ||
| "TEAM", | ||
| "DISTRIBUTION" | ||
| ], | ||
| "filter": "includes" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "type": "Target-LLIN-mz", | ||
| "mappings": [ | ||
| { | ||
| "to": "HCM_ADMIN_CONSOLE_TARGET", | ||
| "from": [ | ||
| "CONFIRMED_HCM_ADMIN_CONSOLE_TARGET_POPULATION" | ||
| ], | ||
| "filter": "equal" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "type": "Target-MR-DN", | ||
| "mappings": [ | ||
| { | ||
| "to": "HCM_ADMIN_CONSOLE_TARGET_SMC_AGE_3_TO_11", | ||
| "from": [ | ||
| "CONFIRMED_HCM_ADMIN_CONSOLE_TARGET_POPULATION_AGE_3TO11" | ||
| ], | ||
| "filter": "equal" | ||
| }, | ||
| { | ||
| "to": "HCM_ADMIN_CONSOLE_TARGET_SMC_AGE_12_TO_59", | ||
| "from": [ | ||
| "CONFIRMED_HCM_ADMIN_CONSOLE_TARGET_POPULATION_AGE_12TO59" | ||
| ], | ||
| "filter": "equal" | ||
| } | ||
| ] | ||
| } | ||
| ] |
There was a problem hiding this comment.
Add security validations for role mappings and target populations
The configuration lacks important security validations:
- Boundary code validation is missing, which could lead to unauthorized access
- No range validation for target population numbers
- No audit trail for mapping changes
Consider implementing these security measures:
- Add boundary code validation pattern
- Add reasonable min/max values for target populations
- Add audit fields (createdBy, createdDate, lastModifiedBy, lastModifiedDate)
Example validation:
{
"type": "Target-LLIN-mz",
"mappings": [
{
"to": "HCM_ADMIN_CONSOLE_TARGET",
"from": [
"CONFIRMED_HCM_ADMIN_CONSOLE_TARGET_POPULATION"
],
- "filter": "equal"
+ "filter": "equal",
+ "validation": {
+ "boundaryCodePattern": "^[A-Z0-9_-]+$",
+ "targetPopulationRange": {
+ "min": 0,
+ "max": 10000000
+ }
+ },
+ "audit": {
+ "createdBy": "",
+ "createdDate": "",
+ "lastModifiedBy": "",
+ "lastModifiedDate": ""
+ }
}
]
}Committable suggestion skipped: line range outside the PR's diff.
🛠️ Refactor suggestion
Add JSON Schema validation and improve documentation
The configuration file needs improvements in validation and documentation:
- Add JSON Schema validation to ensure structural integrity
- Document the purpose and usage of different filter types ("includes" vs "equal")
- Add validation for allowed values in the "from" arrays
- Include descriptions for each mapping type
Apply this diff to improve the structure:
[
+ {
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "description": "Configuration for mapping user roles and target populations",
+ "definitions": {
+ "mapping": {
+ "type": "object",
+ "required": ["to", "from", "filter"],
+ "properties": {
+ "to": { "type": "string" },
+ "from": {
+ "type": "array",
+ "items": { "type": "string" }
+ },
+ "filter": {
+ "type": "string",
+ "enum": ["includes", "equal"],
+ "description": "Filter type: 'includes' for partial matches, 'equal' for exact matches"
+ },
+ "description": { "type": "string" }
+ }
+ }
+ }
+ },
{
+ "description": "Maps user roles to their respective boundaries and teams",
"type": "user",
"mappings": [
{
+ "description": "Maps supervisor role to campaign boundaries and teams",
"to": "Supervisor",
// rest of the mapping...Committable suggestion skipped: line range outside the PR's diff.
| "isStepRequired": true | ||
| } | ||
| ], | ||
| "isHeaderBold": true | ||
| }, | ||
| { | ||
| "header": "USERWITHBOUNDARY_README_HEADER_3", | ||
| "inSheet": true, | ||
| "inUiInfo": true, | ||
| "descriptions": [ | ||
| { | ||
| "text": "USERWITHBOUNDARY_README_HEADER_3_DESC_1", | ||
| "isStepRequired": false | ||
| }, | ||
| { | ||
| "text": "USERWITHBOUNDARY_README_HEADER_3_DESC_2", | ||
| "isStepRequired": false | ||
| } | ||
| ], | ||
| "isHeaderBold": true | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "type": "facilityWithBoundary", | ||
| "texts": [ | ||
| { | ||
| "header": "FACILITYWITHBOUNDARY_README_HEADER_1", | ||
| "inSheet": false, | ||
| "inUiInfo": true, | ||
| "descriptions": [ | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_1_DESC_1", | ||
| "isStepRequired": true | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_1_DESC_2", | ||
| "isStepRequired": true | ||
| } | ||
| ], | ||
| "isHeaderBold": true | ||
| }, | ||
| { | ||
| "header": "FACILITYWITHBOUNDARY_README_HEADER_2", | ||
| "inSheet": true, | ||
| "inUiInfo": true, | ||
| "descriptions": [ | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_1", | ||
| "isStepRequired": true | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_2", | ||
| "isStepRequired": true | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_3", | ||
| "isStepRequired": true | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_4", | ||
| "isStepRequired": true | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_5", | ||
| "isStepRequired": false | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_6", | ||
| "isStepRequired": false | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_2_DESC_7", | ||
| "isStepRequired": false | ||
| } | ||
| ], | ||
| "isHeaderBold": true | ||
| }, | ||
| { | ||
| "header": "FACILITYWITHBOUNDARY_README_HEADER_3", | ||
| "inSheet": true, | ||
| "inUiInfo": true, | ||
| "descriptions": [ | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_3_DESC_1", | ||
| "isStepRequired": false | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_3_DESC_2", | ||
| "isStepRequired": false | ||
| }, | ||
| { | ||
| "text": "FACILITYWITHBOUNDARY_README_HEADER_3_DESC_3", | ||
| "isStepRequired": false | ||
| } | ||
| ], | ||
| "isHeaderBold": true | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve text configuration structure and i18n support
The text configuration needs improvements:
- Text keys use inconsistent naming patterns (e.g., some use underscores, others use dots)
- Missing internationalization support
- No validation for text content format
Consider this improved structure:
[
+ {
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "description": "UI text configurations with i18n support"
+ },
{
"type": "facilityWithBoundary-MP",
"texts": [
{
- "header": "FACILITYWITHBOUNDARY_MP_README_HEADER_1",
+ "header": {
+ "key": "facility.withBoundary.mp.readme.header.1",
+ "translations": {
+ "en": "Facility with Boundary MP",
+ "fr": "Installation avec limite MP"
+ }
+ },
"inSheet": false,
"inUiInfo": true,
"descriptions": [
{
- "text": "FACILITYWITHBOUNDARY_MP_README_HEADER_1_DESC_1",
+ "text": {
+ "key": "facility.withBoundary.mp.readme.header.1.desc.1",
+ "translations": {
+ "en": "Description in English",
+ "fr": "Description en Français"
+ }
+ },
"isStepRequired": true
}
],
"isHeaderBold": true
}
]
}
]Committable suggestion skipped: line range outside the PR's diff.
| "orderNumber": 1 | ||
| }, | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE_MANDATORY_MICROPLAN", | ||
| "type": "string", | ||
| "isRequired": true, | ||
| "description": "Boundary Code", | ||
| "orderNumber": 5, | ||
| "errorMessage": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE_MANDATORY_ERROR" | ||
| } | ||
| ] | ||
| }, | ||
| "campaignType": "microplan3" | ||
| }, | ||
| { | ||
| "title": "facility", | ||
| "$schema": "http://json-schema.org/draft-07/schema#", | ||
| "properties": { | ||
| "enumProperties": [ | ||
| { | ||
| "enum": [ | ||
| "Warehouse", | ||
| "Health Facility", | ||
| "Storing Resource" | ||
| ], | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_TYPE_MICROPLAN", | ||
| "isRequired": true, | ||
| "description": "Facility type", | ||
| "orderNumber": 2 | ||
| }, | ||
| { | ||
| "enum": [ | ||
| "Temporary", | ||
| "Permanent" | ||
| ], | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_STATUS_MICROPLAN", | ||
| "isRequired": true, | ||
| "description": "Facility status", | ||
| "orderNumber": 4 | ||
| }, | ||
| { | ||
| "enum": [ | ||
| "Active", | ||
| "Inactive" | ||
| ], | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_USAGE_MICROPLAN", | ||
| "isRequired": true, | ||
| "description": "Facility usage", | ||
| "orderNumber": 8 | ||
| } | ||
| ], | ||
| "numberProperties": [ | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_CAPACITY_MICROPLAN", | ||
| "type": "number", | ||
| "maximum": 100000000, | ||
| "minimum": 1, | ||
| "isRequired": true, | ||
| "description": "Camapcity", | ||
| "orderNumber": 3, | ||
| "errorMessage": "HCM_ADMIN_CONSOLE_FACILITY_CAPACITY_ERROR" | ||
| }, | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_LATITUDE_MICROPLAN", | ||
| "type": "number", | ||
| "isRequired": true, | ||
| "description": "Latitude", | ||
| "orderNumber": 6 | ||
| }, | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_LONGITUDE_MICROPLAN", | ||
| "type": "number", | ||
| "isRequired": true, | ||
| "description": "Longitude", | ||
| "orderNumber": 7 | ||
| } | ||
| ], | ||
| "stringProperties": [ | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_FACILITY_NAME_MICROPLAN", | ||
| "type": "string", | ||
| "isUnique": true, | ||
| "maxLength": 2000, | ||
| "minLength": 1, | ||
| "isRequired": true, | ||
| "description": "Facility Name", | ||
| "orderNumber": 1 | ||
| }, | ||
| { | ||
| "name": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE_MANDATORY_MICROPLAN", | ||
| "type": "string", | ||
| "isRequired": true, | ||
| "description": "Boundary Code", | ||
| "orderNumber": 5, | ||
| "errorMessage": "HCM_ADMIN_CONSOLE_BOUNDARY_CODE_MANDATORY_ERROR" | ||
| } | ||
| ] | ||
| }, | ||
| "campaignType": "microplan2" | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consolidate duplicate facility schemas
Multiple facility schemas with slight variations are causing maintenance issues and potential inconsistencies. Consider consolidating them using a more flexible structure with conditional fields based on campaign type.
Create a single facility schema with campaign-specific extensions:
{
"title": "facility",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"baseProperties": {
// Common properties for all facility types
},
"campaignSpecificProperties": {
"oneOf": [
{
"campaignType": "microplan",
"properties": {
// Microplan specific properties
}
},
{
"campaignType": "microplan2",
"properties": {
// Microplan2 specific properties
}
}
]
}
}
}Also applies to: 582-973
| { | ||
| "name": "Password", | ||
| "type": "string", | ||
| "description": "password", | ||
| "orderNumber": 10, | ||
| "freezeColumn": true | ||
| } |
There was a problem hiding this comment.
Critical: Remove password field from schema
The schema includes a password field that could expose sensitive data. Passwords should never be stored or transmitted in plain text.
Remove the password field from the schema and handle it through a secure authentication service:
- {
- "name": "Password",
- "type": "string",
- "description": "password",
- "orderNumber": 10,
- "freezeColumn": true
- }
| "actionid": 2030, | ||
| "actioncode": "", | ||
| "tenantid": "mz" | ||
| }, |
There was a problem hiding this comment.
microplan integrator, boundary admin related role actions are mising
| }, | ||
|
|
||
| { | ||
| "id": 2031, |
There was a problem hiding this comment.
add all the actions required
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (3)
mdms/HCM/HCM ADMINCONSOLE v0.3/schemas.json (3)
23-24: Simplify RequestInfo structure by removing null valuesThe RequestInfo object in all schemas contains multiple fields with explicit null values. These could be omitted for better readability and maintainability.
Consider simplifying the RequestInfo structure:
-"RequestInfo": { - "apiId": "asset-services", - "ver": null, - "ts": null, - "action": null, - "did": null, - "key": null, - "msgId": null, - "authToken": "{{authToken}}", - "correlationId": null, - "userInfo": { - "id": "1", - "userName": null, - "name": null, - "type": null, - "mobileNumber": null, - "emailId": null, - "roles": null, - "uuid": "2f5ff063-7d48-419d-9d9d-2c30ef66d199" - } -} +"RequestInfo": { + "apiId": "asset-services", + "authToken": "{{authToken}}", + "userInfo": { + "id": "1", + "uuid": "2f5ff063-7d48-419d-9d9d-2c30ef66d199" + } +}Also applies to: 55-56, 87-88, 119-120, 151-152, 183-184, 215-216, 247-248, 279-280, 311-312, 343-344, 375-376, 407-408, 439-440
13-41: Add descriptions to schema definitionsMost schemas lack proper descriptions which makes it harder to understand their purpose and usage. Consider adding meaningful descriptions like those in the HierarchySchema.
Example for attributeConfig:
{ "code": "HCM-ADMIN-CONSOLE.attributeConfig", - "description": null, + "description": "Defines configuration attributes for campaigns including their keys, codes, and i18n keys", "definition": { "properties": { "key": { + "description": "Unique numeric identifier for the attribute", "type": "number" }, "code": { + "description": "Unique string code for the attribute", "type": "string" }, "i18nKey": { + "description": "Internationalization key for translations", "type": "string" } } } }Also applies to: 45-75, 77-107, 109-139, 141-171, 173-203, 205-235, 237-267, 269-299, 301-331, 333-363, 365-395, 397-427, 429-459, 461-491
471-473: Enhance roleactions schema with additional validation rulesThe roleactions schema could benefit from additional validation rules for its properties.
Consider adding these validations:
{ "properties": { "actionid": { - "type": "string" + "type": "string", + "minLength": 1, + "pattern": "^[a-zA-Z0-9_-]+$" }, "rolecode": { - "type": "string" + "type": "string", + "minLength": 1, + "pattern": "^[A-Z_]+$" }, "tenantid": { - "type": "string" + "type": "string", + "minLength": 2, + "pattern": "^[a-z]+$" } } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/deliveryTypeConfig.json(1 hunks)mdms/HCM/HCM ADMINCONSOLE v0.3/schemas.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- mdms/HCM/HCM ADMINCONSOLE v0.3/JSON DATAS/HCM Admin Console/deliveryTypeConfig.json
| "raw": "https://unified-uat.digit.org/egov-mdms-service/schema/v1/_create", | ||
| "protocol": "https", | ||
| "host": [ | ||
| "unified-uat", | ||
| "digit", | ||
| "org" | ||
| ], | ||
| "path": [ | ||
| "egov-mdms-service", | ||
| "schema", | ||
| "v1", | ||
| "_create" | ||
| ] |
There was a problem hiding this comment.
Remove hardcoded UAT endpoints from schema definitions
The schema creation endpoint URLs are currently hardcoded to the UAT environment (unified-uat.digit.org). This could cause issues when deploying to different environments.
Consider using environment variables or configuration parameters for the host:
-"raw": "https://unified-uat.digit.org/egov-mdms-service/schema/v1/_create"
+"raw": "{{baseUrl}}/egov-mdms-service/schema/v1/_create"Also applies to: 59-71, 91-103, 123-135, 155-167, 187-199, 219-231, 251-263, 283-295, 315-327, 347-359, 379-391, 411-423, 443-455
There was a problem hiding this comment.
why this base url been hardcoded
There was a problem hiding this comment.
@jagankumar-egov, hardcoding the base URL to the UAT environment (unified-uat.digit.org) can cause issues when deploying the application to other environments like production or staging. If the base URL remains hardcoded, the application might unintentionally connect to the wrong environment, leading to potential data inconsistencies or unexpected behavior.
To address this, you can replace the hardcoded URL with a placeholder or variable that can be set based on the environment. For example:
-"raw": "https://unified-uat.digit.org/egov-mdms-service/schema/v1/_create"
+"raw": "{{baseUrl}}/egov-mdms-service/schema/v1/_create"By using {{baseUrl}}, you ensure that the application dynamically points to the correct endpoint based on the deployment environment.
(_/)
(•_•)
(>🤔)
| "mode": "raw", | ||
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"41bc5de2-a03e-456b-9c37-c67f30a4782a\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.HierarchySchema\",\n \"description\": null,\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"Hierarchy Configuration Schema\",\n \"$schema\": \"http://json-schema.org/draft-09/schema#\",\n \"required\": [\n \"hierarchy\",\n \"type\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"enum\": [\n \"default\",\n \"microplan\",\n \"campaign\",\n \"console\"\n ],\n \"type\": \"string\",\n \"description\": \"Specifies the type of hierarchy configuration.\"\n },\n \"group\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of disease groups from the project type master.\"\n },\n \"hierarchy\": {\n \"type\": \"string\",\n \"unique\": true,\n \"description\": \"The type of hierarchy, must be a unique string.\"\n },\n \"department\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of departments from the department master.\"\n },\n \"lowestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The lowest administrative level in the hierarchy.\"\n },\n \"highestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The highest administrative level in the hierarchy.\"\n },\n \"splitBoundariesOn\": {\n \"type\": \"string\",\n \"description\": \"The level on which boundaries are split.\"\n }\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733211297995,\n \"lastModifiedTime\": 1733211297995\n }\n }\n}" |
There was a problem hiding this comment.
Standardize JSON Schema version across all schemas
The HierarchySchema uses draft-09 while all other schemas use draft-07. This inconsistency could lead to validation issues.
Standardize the schema version:
-"$schema": "http://json-schema.org/draft-09/schema#",
+"$schema": "http://json-schema.org/draft-07/schema#",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "mode": "raw", | |
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"41bc5de2-a03e-456b-9c37-c67f30a4782a\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.HierarchySchema\",\n \"description\": null,\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"Hierarchy Configuration Schema\",\n \"$schema\": \"http://json-schema.org/draft-09/schema#\",\n \"required\": [\n \"hierarchy\",\n \"type\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"enum\": [\n \"default\",\n \"microplan\",\n \"campaign\",\n \"console\"\n ],\n \"type\": \"string\",\n \"description\": \"Specifies the type of hierarchy configuration.\"\n },\n \"group\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of disease groups from the project type master.\"\n },\n \"hierarchy\": {\n \"type\": \"string\",\n \"unique\": true,\n \"description\": \"The type of hierarchy, must be a unique string.\"\n },\n \"department\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of departments from the department master.\"\n },\n \"lowestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The lowest administrative level in the hierarchy.\"\n },\n \"highestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The highest administrative level in the hierarchy.\"\n },\n \"splitBoundariesOn\": {\n \"type\": \"string\",\n \"description\": \"The level on which boundaries are split.\"\n }\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733211297995,\n \"lastModifiedTime\": 1733211297995\n }\n }\n}" | |
| "mode": "raw", | |
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"41bc5de2-a03e-456b-9c37-c67f30a4782a\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.HierarchySchema\",\n \"description\": null,\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"Hierarchy Configuration Schema\",\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"required\": [\n \"hierarchy\",\n \"type\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"enum\": [\n \"default\",\n \"microplan\",\n \"campaign\",\n \"console\"\n ],\n \"type\": \"string\",\n \"description\": \"Specifies the type of hierarchy configuration.\"\n },\n \"group\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of disease groups from the project type master.\"\n },\n \"hierarchy\": {\n \"type\": \"string\",\n \"unique\": true,\n \"description\": \"The type of hierarchy, must be a unique string.\"\n },\n \"department\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n },\n \"description\": \"An array of departments from the department master.\"\n },\n \"lowestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The lowest administrative level in the hierarchy.\"\n },\n \"highestHierarchy\": {\n \"type\": \"string\",\n \"description\": \"The highest administrative level in the hierarchy.\"\n },\n \"splitBoundariesOn\": {\n \"type\": \"string\",\n \"description\": \"The level on which boundaries are split.\"\n }\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733211297995,\n \"lastModifiedTime\": 1733211297995\n }\n }\n}" |
There was a problem hiding this comment.
@Satya-egov please check your schema
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| "body": { | ||
| "mode": "raw", | ||
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"e76314da-767a-4599-a659-a56bb7f85b57\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"description\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"isActive\": true,\n \"required\": [\n \"type\",\n \"mappings\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"type\": \"string\"\n },\n \"mappings\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"object\",\n \"properties\": {\n \"to\": {\n \"type\": \"string\"\n },\n \"from\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"filter\": {\n \"enum\": [\n \"includes\",\n \"equal\"\n ],\n \"type\": \"string\",\n \"default\": \"includes\"\n }\n }\n },\n \"minItems\": 1\n }\n },\n \"auditDetails\": {\n \"createdBy\": null,\n \"createdTime\": 1697098069220,\n \"lastModifiedBy\": null,\n \"lastModifiedTime\": 1697098069220\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733479192222,\n \"lastModifiedTime\": 1733479192222\n }\n }\n}" | ||
| }, |
There was a problem hiding this comment.
Remove duplicate auditDetails in microplanIntegration schema
The microplanIntegration schema contains auditDetails both in the definition and at the root level.
Remove the duplicate auditDetails from the definition:
{
"definition": {
"type": "object",
"title": "HCM-ADMIN-CONSOLE.microplanIntegration",
"$schema": "http://json-schema.org/draft-07/schema#",
"isActive": true,
"required": [
"type",
"mappings"
],
- "auditDetails": {
- "createdBy": null,
- "createdTime": 1697098069220,
- "lastModifiedBy": null,
- "lastModifiedTime": 1697098069220
- }
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "body": { | |
| "mode": "raw", | |
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"e76314da-767a-4599-a659-a56bb7f85b57\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"description\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"isActive\": true,\n \"required\": [\n \"type\",\n \"mappings\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"type\": \"string\"\n },\n \"mappings\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"object\",\n \"properties\": {\n \"to\": {\n \"type\": \"string\"\n },\n \"from\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"filter\": {\n \"enum\": [\n \"includes\",\n \"equal\"\n ],\n \"type\": \"string\",\n \"default\": \"includes\"\n }\n }\n },\n \"minItems\": 1\n }\n },\n \"auditDetails\": {\n \"createdBy\": null,\n \"createdTime\": 1697098069220,\n \"lastModifiedBy\": null,\n \"lastModifiedTime\": 1697098069220\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733479192222,\n \"lastModifiedTime\": 1733479192222\n }\n }\n}" | |
| }, | |
| "body": { | |
| "mode": "raw", | |
| "raw": "{\n \"RequestInfo\": {\n \"apiId\": \"asset-services\",\n \"ver\": null,\n \"ts\": null,\n \"action\": null,\n \"did\": null,\n \"key\": null,\n \"msgId\": null,\n \"authToken\": \"{{authToken}}\",\n \"correlationId\": null,\n \"userInfo\": {\n \"id\": \"1\",\n \"userName\": null,\n \"name\": null,\n \"type\": null,\n \"mobileNumber\": null,\n \"emailId\": null,\n \"roles\": null,\n \"uuid\": \"2f5ff063-7d48-419d-9d9d-2c30ef66d199\"\n }\n },\n \"SchemaDefinition\": \n {\n \"id\": \"e76314da-767a-4599-a659-a56bb7f85b57\",\n \"tenantId\": \"mz\",\n \"code\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"description\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"definition\": {\n \"type\": \"object\",\n \"title\": \"HCM-ADMIN-CONSOLE.microplanIntegration\",\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"isActive\": true,\n \"required\": [\n \"type\",\n \"mappings\"\n ],\n \"x-unique\": [\n \"type\"\n ],\n \"properties\": {\n \"type\": {\n \"type\": \"string\"\n },\n \"mappings\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"object\",\n \"properties\": {\n \"to\": {\n \"type\": \"string\"\n },\n \"from\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"filter\": {\n \"enum\": [\n \"includes\",\n \"equal\"\n ],\n \"type\": \"string\",\n \"default\": \"includes\"\n }\n }\n },\n \"minItems\": 1\n }\n }\n },\n \"isActive\": true,\n \"auditDetails\": {\n \"createdBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"lastModifiedBy\": \"8b110055-330f-4e7b-b4c0-f618f29b9d47\",\n \"createdTime\": 1733479192222,\n \"lastModifiedTime\": 1733479192222\n }\n }\n}" | |
| }, |
Summary by CodeRabbit
New Features
Documentation
Bug Fixes