-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abi1 12 11 #1808
Abi1 12 11 #1808
Conversation
📝 WalkthroughWalkthroughThe pull request introduces several changes across multiple files. Notably, the version of the CSS stylesheet linked in two HTML files is updated from Changes
Possibly related PRs
Suggested reviewers
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Outside diff range comments (4)
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchSavedPlans.js (4)
Line range hint
1-9
: Consider enhancing the mergePlanAndCampaign helper functionWhile the function works, there are several opportunities for improvement:
- Add input validation
- Handle cases where campaign is not found
- Optimize the nested find operation
- Add JSDoc documentation
Consider this improved implementation:
+/** + * Merges plan array with campaign details based on campaignId + * @param {Array} planArr - Array of plan configurations + * @param {string} key - Key to store campaign details + * @param {Array} CampaignArr - Array of campaign details + * @returns {Array} Merged array of plans with campaign details + */ const mergePlanAndCampaign = (planArr, key, CampaignArr) => { + if (!Array.isArray(planArr) || !Array.isArray(CampaignArr)) { + return []; + } + // Create campaign lookup map for O(1) access + const campaignMap = new Map( + CampaignArr?.map(campaign => [campaign.id, campaign]) + ); const newArray = planArr?.map((item) => { return { ...item, - [key]: CampaignArr?.find((ele) => ele.id === item.campaignId), + [key]: campaignMap.get(item.campaignId) || null, }; }); return newArray; };
Line range hint
22-35
: Validate campaign IDs before making the API callThe campaign ID extraction and API request preparation could be more robust:
- Validate campaign IDs before making the API call
- Consider handling empty executionPlanIds case
Consider this improvement:
const { PlanConfiguration } = responsePlan; if (!PlanConfiguration || PlanConfiguration.length === 0) return []; const executionPlanIds = PlanConfiguration?.map((row) => row?.campaignId)?.filter((item) => item); + if (!executionPlanIds.length) { + return { + PlanConfiguration, + TotalCount: responsePlan?.TotalCount + }; + } const CampaignDetails = { tenantId: Digit.ULBService.getCurrentTenantId(), ids: executionPlanIds, };
Line range hint
37-49
: Consider using Promise.all for parallel API callsThe current implementation makes sequential API calls. Consider using Promise.all for better performance if the APIs are independent.
Here's a suggested improvement:
- const responseCampaign = await Digit.CustomService.getResponse({ + const [planResponse, campaignResponse] = await Promise.all([ + Digit.CustomService.getResponse({ + url: "/plan-service/config/_search", + useCache: false, + method: "POST", + userService: false, + body, + }), + Digit.CustomService.getResponse({ url: "/project-factory/v1/project-type/search", useCache: false, method: "POST", userService: false, body: { CampaignDetails, }, - }); + }) + ]);
Line range hint
50-63
: Enhance error handling with specific error typesThe error handling could be more specific to help with debugging and user feedback.
Consider this improvement:
return finalResponse; } catch (error) { + const errorMessage = error?.response?.data?.Errors?.[0]?.message; if (error?.response?.data?.Errors) { - throw new Error(error.response.data.Errors[0].message); + throw new Error(`Plan service error: ${errorMessage}`); + } else if (error?.response?.status === 404) { + throw new Error('Required service endpoints not found'); + } else if (error?.response?.status === 401) { + throw new Error('Authentication failed'); } - throw new Error("An unknown error occurred"); + throw new Error(`Failed to fetch plan data: ${error.message || 'Unknown error'}`); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (1)
health/micro-ui/web/micro-ui-internals/packages/css/package.json
is excluded by!**/*.json
📒 Files selected for processing (7)
health/micro-ui/web/micro-ui-internals/example/public/index.html
(1 hunks)health/micro-ui/web/micro-ui-internals/example/src/UICustomizations.js
(1 hunks)health/micro-ui/web/micro-ui-internals/packages/css/src/components/microplan.scss
(1 hunks)health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js
(1 hunks)health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchSavedPlans.js
(1 hunks)health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js
(1 hunks)health/micro-ui/web/public/index.html
(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
health/micro-ui/web/micro-ui-internals/example/src/UICustomizations.js (1)
Pattern **/*.js
: check
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js (1)
Pattern **/*.js
: check
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchSavedPlans.js (1)
Pattern **/*.js
: check
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js (1)
Pattern **/*.js
: check
🪛 Biome
health/micro-ui/web/micro-ui-internals/example/src/UICustomizations.js
[error] 795-795: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
🔇 Additional comments (6)
health/micro-ui/web/micro-ui-internals/example/public/index.html (1)
15-15
: LGTM! Version update aligns with display fixes.
The CSS version update from 0.1.30 to 0.1.32 is consistent with the PR's objective to fix display issues with finalized microplans.
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js (1)
44-44
: LGTM! Verify integration with UICustomizations changes.
The comment removal is clean and doesn't affect functionality. However, since the AI summary mentions related changes in UICustomizations.js affecting data handling, let's verify the integration.
✅ Verification successful
Let me analyze the relationship between MicroplanSearch and UICustomizations further by checking the imports and tab change handling.
Let me check how the TabSearchconfig is connected to UICustomizations to complete the verification.
Based on the complete analysis of the code and verification results, I can now provide the final response:
The onTabChange
integration is correctly implemented and safe to approve
The removal of the comment from onTabChange
prop is safe because:
- The tab change functionality is properly integrated with URL parameters and state management
- The changes in UICustomizations.js don't directly impact this component as they operate at different levels:
- MicroplanSearch handles tab UI state and navigation
- UICustomizations handles data transformations based on the tab state (via URL parameters)
The integration works through the URL parameter tabId
which both components use independently, maintaining loose coupling and proper separation of concerns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the relationship between MicroplanSearch and UICustomizations
# Check for any direct imports or usage of UICustomizations
rg -l "UICustomizations" --type js
# Look for any components that might be affected by the status condition
# mentioned in the AI summary
rg "RESOURCE_ESTIMATIONS_APPROVED" --type js -A 5
Length of output: 10302
Script:
#!/bin/bash
# Check imports and tab change handling in MicroplanSearch
rg -A 5 "onTabChange" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js
# Check if MicroplanSearch imports UICustomizations
rg "import.*UICustomizations" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js
# Check the full content of MicroplanSearch to understand the tab change context
cat health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/MicroplanSearch.js
Length of output: 2784
Script:
#!/bin/bash
# Check the MicroplanSearchConfig content
cat health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/MicroplanSearchConfig.js
# Check if MicroplanSearchConfig imports or uses UICustomizations
rg -A 5 "TabSearchconfig" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/MicroplanSearchConfig.js
Length of output: 4633
health/micro-ui/web/micro-ui-internals/packages/css/src/components/microplan.scss (2)
338-338
: LGTM! Consistent table cell spacing.
The removal of margin from paragraph elements within table cells helps maintain consistent spacing and alignment.
340-341
: Verify accessibility impact of transparent popup overlay.
Setting the popup overlay background to transparent might affect content visibility and contrast ratios. Please ensure this change:
- Maintains sufficient contrast between popup content and the underlying page
- Doesn't impact the visual hierarchy of the interface
- Meets WCAG accessibility guidelines
✅ Verification successful
Based on the search results, I can now provide a final response since I have found sufficient context about the popup implementation:
Setting transparent background is safe due to nested popup structure
The transparent background on .digit-popup-overlay
is acceptable because:
- The actual popup overlay background is handled by
.digit-popup-wrap
which hasbackground: rgba(0, 0, 0, 0.7)
- The popup content itself is wrapped in
.digit-popup-wrapper
which maintains proper contrast - The z-index layering (z-index: 10000) ensures proper visual hierarchy
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for related popup overlay styles that might provide additional background or contrast
rg -g '*.{scss,css}' --no-heading 'digit-popup' -A 5 -B 5
Length of output: 16649
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js (1)
77-81
: Verify the visibility of approved microplans.
Let's verify that removing userUuid allows all users to view approved microplans and doesn't have unintended side effects.
✅ Verification successful
Based on the search results, I can now provide a conclusive response about the visibility of approved microplans:
Removing userUuid for RESOURCE_ESTIMATIONS_APPROVED status is safe and intentional
The code change is part of a consistent pattern where:
- By default, microplans are filtered by the current user's UUID
- For approved microplans (RESOURCE_ESTIMATIONS_APPROVED status), the userUuid filter is intentionally removed to make them visible to all users
- This behavior is isolated to the search criteria modification and doesn't have unintended side effects
The implementation is consistent across both the main module and example implementations, indicating this is the intended behavior for approved microplans.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the removal of userUuid is handled consistently across the codebase
# Check for any other conditions or places where userUuid is handled for approved microplans
rg -A 5 "RESOURCE_ESTIMATIONS_APPROVED.*userUuid|userUuid.*RESOURCE_ESTIMATIONS_APPROVED"
# Check for any API handlers or backend validations related to this status
ast-grep --pattern 'RESOURCE_ESTIMATIONS_APPROVED'
Length of output: 142
Script:
#!/bin/bash
# Let's try a broader search to understand the context and usage of RESOURCE_ESTIMATIONS_APPROVED
# Search for any mentions of RESOURCE_ESTIMATIONS_APPROVED
rg "RESOURCE_ESTIMATIONS_APPROVED"
# Search for userUuid usage in the same file
rg "userUuid" "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js"
# Look for any other status checks in the same file
rg "status\[0\]" "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/UICustomizations.js"
# Check for any API configurations or search criteria handling
rg "PlanConfigurationSearchCriteria" -A 5
Length of output: 38350
🧰 Tools
🪛 Biome
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
health/micro-ui/web/micro-ui-internals/example/src/UICustomizations.js (1)
794-798
: Verify access control implications
The removal of userUuid filter for approved microplans makes them visible to all users. Please verify this is the intended behavior and aligns with the access control requirements.
✅ Verification successful
Let me gather more information about the access control implementation by checking for related API calls and configurations.
Let me search for any role-based access control configurations that might be relevant to the microplan visibility.
Based on the code analysis, I can now provide a final response about the access control implications:
Removal of userUuid filter for approved microplans is intentional and safe
The removal of userUuid filter for RESOURCE_ESTIMATIONS_APPROVED status is an intentional design choice that aligns with the workflow. This is because:
- The userUuid filter is only removed for microplans in "RESOURCE_ESTIMATIONS_APPROVED" status, maintaining user-specific visibility for all other statuses
- The tenantId filter remains in place, ensuring organizational boundaries are maintained
- The approved status represents a finalized state where wider visibility is beneficial for operational purposes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any access control related configurations or documentation
# Look for related access control configurations
rg -A 5 "RESOURCE_ESTIMATIONS_APPROVED" --type js
# Check for any documentation about access control
fd -e md -e txt . -x grep -l "microplan.*access.*control" {} \;
Length of output: 8787
Script:
#!/bin/bash
# Search for API endpoints and configurations related to microplan access
rg -A 5 "PlanConfigurationSearchCriteria" --type js
# Look for any role-based access control or permission checks
rg -A 5 "userUuid|isAuthorized|hasAccess|canAccess|permissions" --type js health/micro-ui/web/micro-ui-internals/packages/modules/microplan/
Length of output: 38614
Script:
#!/bin/bash
# Search for role-based configurations and status transitions
rg -A 5 "RESOURCE_ESTIMATIONS_APPROVED.*role|role.*RESOURCE_ESTIMATIONS_APPROVED" --type js
# Look for any workflow or state transition configurations
rg -A 10 "workflowDetails|workflow.*config|state.*transition" --type js health/micro-ui/web/micro-ui-internals/packages/modules/microplan/
Length of output: 1479
🧰 Tools
🪛 Biome
[error] 795-795: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
@@ -12,7 +12,7 @@ | |||
<title>DIGIT</title> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-css@1.8.2-beta.49/dist/index.css" /> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-components-css@0.0.2-beta.39/dist/index.css" /> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.30/dist/index.css" /> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.32/dist/index.css" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick (assertive)
Consider production deployment optimizations.
While using unpkg.com CDN is convenient for development, consider the following improvements for production:
- Add integrity hashes to prevent supply chain attacks
- Consider self-hosting these assets or using a reliable enterprise CDN
- Implement CSS versioning strategy that allows for easier rollbacks
Example implementation with integrity hash:
- <link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.32/dist/index.css" />
+ <link rel="stylesheet"
+ href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.32/dist/index.css"
+ integrity="sha384-[HASH]"
+ crossorigin="anonymous" />
Committable suggestion skipped: line range outside the PR's diff.
@@ -10,7 +10,7 @@ | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-css@1.8.2-beta.49/dist/index.css" /> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-components-css@0.0.2-beta.39/dist/index.css" /> | |||
<!-- added below css for hcm-workbench module inclusion--> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.30/dist/index.css" /> | |||
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-health-css@0.1.32/dist/index.css" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Version mismatch: Package published but not available on CDN
The package @egovernments/digit-ui-health-css
version 0.1.32 is defined in the source package.json but not accessible via unpkg CDN, while version 0.1.30 is still available. This indicates the new version might not be properly published or synchronized with the CDN yet.
- Package version 0.1.32 is defined in
health/micro-ui/web/micro-ui-internals/packages/css/package.json
- The version is referenced in HTML files but returns 404 on unpkg
- Previous version 0.1.30 is still accessible on CDN
🔗 Analysis chain
Verify the health CSS package version update.
The CSS version update looks good, following proper versioning practices with a specific version number.
Let's verify the package version and consistency:
Package version 0.1.32 is not available on unpkg CDN
The CSS package version 0.1.32 referenced in the HTML files is not accessible on the unpkg CDN (404 response). This could lead to broken styles in the application.
health/micro-ui/web/public/index.html
health/micro-ui/web/micro-ui-internals/example/public/index.html
Let's verify if the previous version is still available:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the health CSS package version across files and its availability
# Check if the new version exists on unpkg
curl -s -o /dev/null -w "%{http_code}" https://unpkg.com/@egovernments/digit-ui-health-css@0.1.32/dist/index.css
# Check for consistent versions across all HTML files
echo "Checking version consistency across files:"
rg -A 1 "digit-ui-health-css@" --type html
Length of output: 756
Script:
#!/bin/bash
# Check if previous version exists
curl -s -o /dev/null -w "%{http_code}" https://unpkg.com/@egovernments/digit-ui-health-css@0.1.30/dist/index.css
# List available versions in package.json if it exists
echo "Checking package.json for version info:"
fd package.json --exec grep -l "digit-ui-health-css" {} \; --exec cat {}
Length of output: 1877
if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){ | ||
delete data.body.PlanConfigurationSearchCriteria.userUuid | ||
|
||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick (assertive)
LGTM! Consider minor formatting improvements.
The logic to remove userUuid for approved microplans is correct, making them visible to all users. Consider these minor formatting improvements:
- if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){
- delete data.body.PlanConfigurationSearchCriteria.userUuid
-
-
- }
+ if (data.body.PlanConfigurationSearchCriteria.status?.[0] === "RESOURCE_ESTIMATIONS_APPROVED") {
+ delete data.body.PlanConfigurationSearchCriteria.userUuid;
+ }
📝 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.
if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){ | |
delete data.body.PlanConfigurationSearchCriteria.userUuid | |
} | |
if (data.body.PlanConfigurationSearchCriteria.status?.[0] === "RESOURCE_ESTIMATIONS_APPROVED") { | |
delete data.body.PlanConfigurationSearchCriteria.userUuid; | |
} |
🧰 Tools
🪛 Biome
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){ | ||
delete data.body.PlanConfigurationSearchCriteria.userUuid | ||
|
||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick (assertive)
Consider using undefined assignment instead of delete operator
The logic to remove the userUuid filter for approved microplans is correct. However, using the delete operator can impact performance.
Consider this alternative approach:
- if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){
- delete data.body.PlanConfigurationSearchCriteria.userUuid
- }
+ if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){
+ data.body.PlanConfigurationSearchCriteria.userUuid = undefined;
+ }
📝 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.
if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){ | |
delete data.body.PlanConfigurationSearchCriteria.userUuid | |
} | |
if(data.body.PlanConfigurationSearchCriteria.status && data.body.PlanConfigurationSearchCriteria.status[0]==="RESOURCE_ESTIMATIONS_APPROVED"){ | |
data.body.PlanConfigurationSearchCriteria.userUuid = undefined; | |
} | |
🧰 Tools
🪛 Biome
[error] 795-795: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
Now finalise microplans will show the data correctly, and css changes
Summary by CodeRabbit
New Features
Bug Fixes
Style