feat(admin): adding uniformity in cancel and back buttons present in SERVICES

[faisalsiddique4400]

feat(admin): adding uniformity in cancel and back buttons present in SERVICES

Summary

This update introduces consistent behavior for Cancel, Back, and Apply buttons across Admin UI forms, including correct enabling and disabling based on form state.

Improvements

Button	Updated Behavior
Cancel	Resets all fields to their previous values without navigating away. Disabled until a change is made.
Back	Navigates to the previous page. If there is no navigation history, returns to Dashboard. Always enabled.
Apply	Saves the changes without leaving the page. Enabled only when the form has unsaved changes.

Additional Enhancements

• Buttons now correctly detect dirty form states.
• Apply button is dynamically enabled and disabled based on whether changes exist.
• Cancel button is disabled until a field is modified.
• Prevents accidental navigation or state loss in multi step configuration pages.

Affected Modules

This change is applied across all forms where configuration changes are possible, including but not limited to:

• SERVICES

Parent issue: #2268

Testing Steps

1. Open suggested config form.
2. Modify any field.
3. Verify that:
   • Apply and Cancel buttons become enabled.
   • Apply saves configuration and stays on page.
   • Cancel reverts values and disables itself afterward.
4. Back button should navigate appropriately.

Summary by CodeRabbit

• Bug Fixes

  • Fixed form validation feedback by correcting when submit buttons are disabled.
  • Improved loading state indicators to accurately reflect submission status during form operations.

• Improvements

  • Enhanced form footer components for consistent behavior across configuration pages.

[coderabbitai]

📝 Walkthrough

Walkthrough

Multiple admin-UI components are updated to improve form state handling: a modal dialog now tracks state changes to reset user messages on open using refs; form footer disable logic is refined to consider form validity and touch state; and loading indicators are defaulted to false when submission state is undefined using nullish coalescing.

Changes

Cohort / File(s)	Summary
Modal state tracking and reset admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx	Added useRef to track modal open/close transitions; simplified active-state logic; reset userMessage on modal open transition; extended effect dependencies to include modal; updated renderBadges callback signature.
FIDO form footer behavior admin-ui/plugins/fido/components/DynamicConfiguration.tsx, admin-ui/plugins/fido/components/StaticConfiguration.tsx	Updated disableApply logic to disable when form is invalid or untouched (instead of dirty only); default isLoading to false using nullish coalescing when isSubmitting is undefined.
SCIM form loading state admin-ui/plugins/scim/components/ScimConfiguration.tsx	Changed isLoading prop passed to GluuFormFooter to use nullish coalescing (isSubmitting ?? false) to ensure boolean default when isSubmitting is undefined.
Services configuration footer replacement and logic admin-ui/plugins/services/Components/Configuration/CachePage.js	Replaced GluuCommitFooter with GluuFormFooter; removed local submitForm helper; updated footer props for visibility and state control; refactored modal handler to call formik.handleSubmit before modal toggle.
Services persistence footer addition admin-ui/plugins/services/Components/Configuration/PersistenceDetail.js	Added GluuFormFooter component with showBack={true}, showCancel={false}, showApply={false}.
SMTP form loading state admin-ui/plugins/smtp-management/components/SmtpForm.tsx	Changed isLoading to wire to formik.isSubmitting with nullish coalescing default, replacing static false to show loading state during submission.

Sequence Diagram

sequenceDiagram
    participant User
    participant Modal as GluuCommitDialog
    participant Ref as prevModalRef
    participant Effect as useEffect
    participant State as userMessage State

    User->>Modal: Opens modal
    Modal->>Effect: Run effect (active changed)
    Effect->>Ref: Check prevModalRef.current
    
    alt First open transition
        Ref-->>Effect: prevModalRef null/false
        Effect->>State: Reset userMessage to ""
        Effect->>Ref: Update prevModalRef.current = true
    else Already open
        Ref-->>Effect: prevModalRef true
        Effect-->>Effect: Skip reset
    end

    Note over Effect: activeState = userMessage.length > 0
    Effect-->>Modal: Update active state

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Modal refactor with ref tracking: The useRef pattern for tracking state transitions and conditional effects requires careful verification of the reset logic and lifecycle timing.
• Form disable logic changes: Multiple components update disable conditions with different contexts (invalid vs. untouched); each requires verification that the new conditions are appropriate for their specific forms.
• Nullish coalescing pattern: Applied consistently across FIDO, SCIM, and SMTP, but each integration point needs review to ensure undefined cases are handled correctly.
• Footer component replacement: The swap from GluuCommitFooter to GluuFormFooter in CachePage involves prop remapping and modal handler logic that needs validation against the old behavior.

Possibly related PRs

• feat(admin): adding uniformity in cancel and back buttons present in SMTP #2410: Updates GluuFormFooter defaults and replaces GluuCommitFooter in SMTP components, sharing the same form footer refactoring patterns.
• fix(admin-ui): unable to add Custom properties and Module properties in Scripts page #2401 #2402: Modifies modal dialog state tracking to reset messages on open, using similar effect-based reset patterns.
• feat(admin): adding uniformity in cancel and back buttons present in Jans Lock #2405: Adjusts form footer button disable logic and isSubmitting/isLoading wiring across multiple form components.

Suggested labels

comp-admin-ui

Suggested reviewers

• syntrydy
• duttarnab

Poem

🐰 A modal's memory, cleared with care,
Forms now know when they're not quite fair,
Refs track the dance of open and close,
Loading states bloom where submission flows,
Footers aligned from here to there! ✨

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'feat(admin): adding uniformity in cancel and back buttons present in SERVICES' clearly and concisely summarizes the main objective of the changeset. It accurately reflects the primary focus: introducing consistent behavior for Cancel, Back, and Apply buttons across Admin UI forms, specifically in the SERVICES modules. The title is specific enough for teammates to understand the core change without being overly detailed.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch admin-ui-issue-2361-services

---

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

[faisalsiddique4400]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

admin-ui/plugins/services/Components/Configuration/CachePage.js (1)

90-95: Cancel handler correctly resets both form and local state.

The implementation properly resets the Formik form and the local cacheProviderType state, ensuring the UI reflects the cancellation. This aligns with the PR objective that Cancel should reset all fields to previous values.

Optional: Consider memoizing with useCallback for performance.

Since handleCancel is recreated on every render, wrapping it in useCallback could prevent unnecessary re-renders of GluuFormFooter if that component is memoized:

const handleCancel = useCallback((formik) => {
  return () => {
    formik.resetForm()
    setCacheProviderType(cacheData.cacheProviderType)
  }
}, [cacheData.cacheProviderType])

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d8957fd and 795eb35.

📒 Files selected for processing (7)

• admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx (3 hunks)
• admin-ui/plugins/fido/components/DynamicConfiguration.tsx (1 hunks)
• admin-ui/plugins/fido/components/StaticConfiguration.tsx (1 hunks)
• admin-ui/plugins/scim/components/ScimConfiguration.tsx (1 hunks)
• admin-ui/plugins/services/Components/Configuration/CachePage.js (2 hunks)
• admin-ui/plugins/services/Components/Configuration/PersistenceDetail.js (2 hunks)
• admin-ui/plugins/smtp-management/components/SmtpManagement/SmtpForm.tsx (1 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2404
File: admin-ui/app/routes/Apps/Gluu/Gluuformfooter.tsx:70-77
Timestamp: 2025-11-03T08:47:33.926Z
Learning: In the admin-ui forms (Gluuformfooter component), the Back button should always navigate to '/home/dashboard' rather than using history-based navigation (navigate(-1)), as clarified by faisalsiddique4400 in PR #2404.

📚 Learning: 2025-11-03T08:47:33.926Z

Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2404
File: admin-ui/app/routes/Apps/Gluu/Gluuformfooter.tsx:70-77
Timestamp: 2025-11-03T08:47:33.926Z
Learning: In the admin-ui forms (Gluuformfooter component), the Back button should always navigate to '/home/dashboard' rather than using history-based navigation (navigate(-1)), as clarified by faisalsiddique4400 in PR #2404.

Applied to files:

• admin-ui/plugins/services/Components/Configuration/PersistenceDetail.js
• admin-ui/plugins/services/Components/Configuration/CachePage.js

🔇 Additional comments (1)

admin-ui/plugins/services/Components/Configuration/CachePage.js (1)

238-241: Remove this review comment—the suggested changes are based on a misunderstanding of the Formik API.

The formik.handleSubmit() method is synchronous and does not return an awaitable promise. It validates the form and invokes the onSubmit callback. Async Redux operations are handled separately via Redux middleware, and the loading state is correctly displayed via the BlockUi component.

The current pattern in CachePage.js (calling formik.handleSubmit() synchronously, then closing the modal) is consistent with the rest of the codebase and is correct. The Redux loading state provides user feedback about async operations while the modal closes immediately as intended.

No changes are required.

Likely an incorrect or invalid review comment.