[Customer portal] [Web] Enhance Product Update Workflow with Improved State Management and Refactored Component Interfaces

[dileepapeiris]

Description

This pull request introduces improvements to the product update workflow in the customer portal, focusing on enhanced state management and UI responsiveness for adding updates, as well as refactoring component interfaces for better flexibility. The most important changes are grouped below:

Product Update Workflow Enhancements

• Added addUpdateState to ManageProductModal, allowing the modal to track whether an update can be added, whether saving is in progress, and providing a callback for adding updates. This enables more responsive UI controls and prevents duplicate submissions.
• Updated the modal's footer to display either a loading spinner or an "Add Update" button based on the current form state, improving user feedback during update operations.
• Disabled the "Close" button while saving or when an update is in progress, preventing interruptions during update operations.

Component Interface Refactoring

• Replaced the onClose prop in UpdateHistoryTab with a more flexible onFormStateChange callback, allowing parent components to react to form validity and saving state. [1] [2]
• Added logic in UpdateHistoryTab to notify the parent of form state changes, enabling improved coordination between modal and tab components.
• Modified the footer of UpdateHistoryTab to conditionally render controls based on whether the parent manages form state, increasing component reusability.

Project Details Page Improvements

• Refactored ProjectDetails to use useInfiniteProjects and flattenProjectPages for retrieving all projects, ensuring the project type label is always up-to-date and improving logic for hiding deployments and time tracking sections. [1] [2] [3]
• Updated layout structure in ProjectDetails for improved maintainability and consistency. [1] [2]

Minor Improvements and Fixes

• Added useEffect in TimelineItem to reset edit form state when the update or editing state changes, ensuring form data remains consistent.
• Removed obsolete onClose prop from test setup for UpdateHistoryTab.

These changes collectively improve the reliability and user experience of managing product updates within the portal.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes refactor the "Add Update" form flow by shifting state management from the child UpdateHistoryTab component to the parent ManageProductModal, introducing a onFormStateChange callback prop for better parent-level control. Additionally, ProjectDetails now derives project type information from a separate paginated dataset instead of the main query.

Changes

Cohort / File(s)	Summary
Modal Form State Management ManageProductModal.tsx, UpdateHistoryTab.tsx, UpdateHistoryTab.test.tsx	Refactored "Add Update" flow to use parent-controlled state; replaced onClose callback with onFormStateChange prop to communicate form validity and handlers to parent modal. Updated modal's Close button and DialogActions to reflect form state. Removed onClose from test fixture.
Project Data Fetching ProjectDetails.tsx	Modified to fetch project data from infinite-query dataset, deriving currentProject and projectTypeLabel from flattened results rather than main query. Updated JSX wrapper from fragment to Box component.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Feat/add update page #228 — Introduces the original ManageProductModal and UpdateHistoryTab components that are being refactored here.
• [Customer Portal][Web] Add Editable Update History Feature for Deployment Products with Full CRUD Support #383 — Modifies the same components with related changes to the "Add Update" flow architecture.

Suggested labels

Type/New Feature, Type/UX, App/Customer Portal, Area/Frontend, Platform/Web

Suggested reviewers

• Rashmika998
• shayanmalinda

Poem

🐰 A hop, a skip, state flows up high,
From child to parent, no more goodbye!
Forms now dance to modal's sweet tune,
Projects infinite, beneath the moon 🌙
Updates gather, clean and bright,
Our refactor shines so right!

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description consists entirely of the empty template with placeholder text; no actual content is filled in for any of the required sections (Purpose, Goals, Approach, User Stories, etc.).	Complete all required template sections with concrete details about the problem being solved, the implementation approach, relevant issues/PRs, and test coverage information.
Title check	❓ Inconclusive	The title 'Feat add update history' is vague and generic, using only broad terms without specifying what aspect of update history was added or what problem it solves.	Provide a more specific and descriptive title that clarifies the primary change, such as 'Expose update history form state to parent modal' or 'Add update history management to product modal'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@apps/customer-portal/webapp/src/components/project-details/deployments/ManageProductModal.tsx`:
- Around line 324-327: The modal can still be closed during a save because only
the footer Close Button is disabled; update the close logic by moving the busy
guard into handleClose (check isSubmitting || addUpdateState?.isSaving at the
top of handleClose and return early if busy) and then reuse handleClose
everywhere that can dismiss the Dialog (pass handleClose to Dialog's onClose and
the title-bar X onClick) so all dismissal paths respect the same guard.

In
`@apps/customer-portal/webapp/src/components/project-details/deployments/UpdateHistoryTab.tsx`:
- Around line 46-50: Change the lifted callback contract to accept a nullable
state and clear it on unmount: update the prop type signature for
onFormStateChange to accept (state: { canAdd: boolean; isSaving: boolean;
handleAdd: () => void; } | null) => void, and in the component that
sets/publishes the form state (the effect that calls onFormStateChange with {
canAdd, isSaving, handleAdd }) add a cleanup that calls
onFormStateChange?.(null) so the previous handleAdd is cleared when the tab
unmounts; apply the same nullable contract and unmount cleanup to the other
similar publisher (the second occurrence referenced in the review) and ensure
ManageProductModal consumers handle a null state.

In `@apps/customer-portal/webapp/src/pages/ProjectDetails.tsx`:
- Around line 56-63: The page is using the partial cache from
useInfiniteProjects + flattenProjectPages to derive currentProject and
projectTypeLabel, which can be undefined if the projectId isn't in the cached
pages; update the logic in ProjectDetails.tsx so that after computing
currentProject from flattenProjectPages(projectsData) you fall back to the exact
project details response (the hook or prop that returns the single project's
data) or trigger paging until the projectId is found; specifically, keep the
existing useInfiniteProjects and flattenProjectPages usage but if currentProject
is undefined then read from the project-details response (or call the
single-project hook) and set projectTypeLabel from that source (or loop/fetch
additional pages) so tab visibility is driven by the authoritative
project-details data rather than the partial projects cache.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: d74a8d5d-2e6e-47fb-a41f-14c473a46a9f

📥 Commits

Reviewing files that changed from the base of the PR and between f397a26 and 453a359.

📒 Files selected for processing (4)

• apps/customer-portal/webapp/src/components/project-details/deployments/ManageProductModal.tsx
• apps/customer-portal/webapp/src/components/project-details/deployments/UpdateHistoryTab.tsx
• apps/customer-portal/webapp/src/components/project-details/deployments/__tests__/UpdateHistoryTab.test.tsx
• apps/customer-portal/webapp/src/pages/ProjectDetails.tsx

💤 Files with no reviewable changes (1)

• apps/customer-portal/webapp/src/components/project-details/deployments/tests/UpdateHistoryTab.test.tsx