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

[faisalsiddique4400]

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

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:

• SCIM
• SAML
• Authentication
• FIDO
• Jans Lock
• Services (Cache, Logging)
• Auth Server (Config API Properties, Auth Server Properties)
• Application Settings

Parent issue: #2268

Testing Steps

1. Open any 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
  • Prevented empty arrays/objects from being included in configuration updates, avoiding unnecessary submission operations.
  • Improved form submission state tracking so the Apply button shows loading and disable state reflects ongoing submissions and form validity.
  • More robust handling of channel/token input shapes to avoid errors with string or object values.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR wires the patch mutation's pending state into the JansLock configuration form, adds memoized trimmed-values/patch computation and form dirty/valid checks, updates footer actions to use those flags and submission state, and prevents emitting add patch operations for empty arrays/objects.

Changes

Cohort / File(s)	Summary
Top-level wiring & form props admin-ui/plugins/jans-lock/components/JansLock.tsx, admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx	Passes isSubmitting={patchMutation.isPending} from JansLock to JansLockConfiguration. JansLockConfiguration adds isSubmitting?: boolean prop, uses useMemo to compute trimmed values and patch operations, derives isFormDirty and isFormValid, and updates footer actions/disable/loading logic to use those flags.
Patch operation generation admin-ui/plugins/jans-lock/helper/utils.ts	createPatchOperations now checks for empty arrays and empty objects in normalized values and skips emitting add operations for empty structures; non-empty values and replace semantics unchanged.
Utility typing and traversal admin-ui/app/utils/Util.ts	Broadened trimObjectStrings generic from Record<string, unknown> to object, introduced a local source typed as record for iteration, and adjusted recursion/handling to preserve non-string primitives and trim nested plain objects.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant UI as JansLock (parent)
  participant Form as JansLockConfiguration
  participant Mut as patchMutation
  participant Utils as createPatchOperations

  UI->>Form: render(isLoading, isSubmitting = Mut.isPending)
  Form->>Form: compute trimmedValuesAndPatches (useMemo)
  Form->>Form: compute isFormDirty / isFormValid (useMemo)
  alt user clicks Apply
    Form->>Mut: mutate(patchOperations)
    Mut-->>Form: isPending true (prop updates)
    Form->>Form: footer shows isLoading / disabled per flags
  end

  Note over Form,Utils: createPatchOperations skips add ops for empty arrays/objects

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Review memoization correctness and dependency arrays in JansLockConfiguration.tsx.
• Verify isFormDirty and isFormValid accurately reflect trimmed form state.
• Confirm footer action wiring (onApply/onCancel/disable/isLoading) uses the new prop as intended.
• Validate empty-structure detection in helper/utils.ts to ensure no legitimate patches are skipped.

Suggested labels

comp-admin-ui

Suggested reviewers

• syntrydy

Poem

🐇 A rabbit hums beside the trees,
Trimming values with gentle ease.
Empty nests are left alone,
Submit-light glows, a tiny cone—
Configs hop safe into their lease.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "adding uniformity in cancel and back buttons present in Jans Lock" effectively conveys the main objective of the changeset, which is to standardize button behavior in the Jans Lock configuration form. The title correctly identifies the specific module (Jans Lock) and the core theme of the changes (button uniformity). However, the title specifically mentions only "cancel and back buttons" while the PR objectives and code changes indicate that the Apply button behavior is equally important and standardized as part of this effort. Despite this minor omission, the title is clear, concise, and communicates the primary intent—a teammate reviewing history would understand that this PR addresses button standardization in Jans Lock configuration.

✨ 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-jans-lock

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1e75123 and 7d57748.

📒 Files selected for processing (2)

• admin-ui/app/utils/Util.ts (1 hunks)
• admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (6 hunks)

🔇 Additional comments (8)

admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (8)

2-2: LGTM!

The useMemo import is correctly added and properly used for memoizing trimmedValuesAndPatches, isFormDirty, and isFormValid.

---

23-23: LGTM!

The optional isSubmitting prop is correctly typed and appropriately used to wire submission state from the parent component's mutation into the footer's loading indicator.

---

62-72: Memoization successfully addresses previous feedback.

The trimmedValuesAndPatches memoization eliminates the duplicate trimming and patch computation that was flagged in the previous review. The implementation correctly handles null cases and properly declares return types.

The type assertion on line 69 appears significantly cleaner than the previous double-cast pattern (as unknown as Record<string, unknown>) as unknown as JansLockConfigFormValues), likely due to the improved trimObjectStrings signature in Util.ts that now accepts T extends object.

Based on previous review comments.

---

74-76: LGTM!

The isFormDirty check correctly derives state from the memoized patches, ensuring Cancel and Apply buttons react to actual changes rather than just field touches. This aligns with the PR's standardization goals.

---

78-83: LGTM!

The isFormValid check properly validates form state synchronously, ensuring the Apply button is only enabled when the form is both dirty and valid per the PR objectives.

---

85-102: LGTM!

The submit callback correctly uses the memoized patchOperations, eliminating redundant computation. The silent no-op for unchanged forms (line 99 comment) provides better UX than showing unnecessary toast notifications.

Dependencies are correctly updated to reflect the memoization strategy.

---

132-132: Type handling correctly aligns with schema.

The cast to string[] now matches the formal type definition from jans-lock-types.ts, addressing previous concerns about mixed-type arrays. The onChange handler (lines 118-131) appropriately handles GluuTypeAhead's polymorphic return type by filtering to extract string values.

The past review suggestion to extract the custom option type ({ customOption: boolean; tokenChannels: string }) as a named constant remains unaddressed but is a low-priority refinement.

Based on previous review comments.

---

433-442: Footer correctly implements standardized button behavior.

The button configuration properly implements the PR objectives:

• Cancel (line 439): disabled when !isFormDirty, calls handleCancel to reset
• Back (line 438): always enabled for navigation
• Apply (line 440): disabled when invalid or clean, triggers submission with loading state

The isSubmitting ?? false pattern on line 442 addresses the previous review comment about unnecessary double negation, providing an explicit boolean fallback that's more readable than !!isSubmitting.

Based on PR objectives and previous review comments.

---

_{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

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5dc0919 and a85773e.

📒 Files selected for processing (3)

• admin-ui/plugins/jans-lock/components/JansLock.tsx (1 hunks)
• admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (4 hunks)
• admin-ui/plugins/jans-lock/helper/utils.ts (1 hunks)

🔇 Additional comments (5)

admin-ui/plugins/jans-lock/helper/utils.ts (1)

107-121: LGTM! Good defensive guard against empty values.

The logic correctly identifies and filters out empty arrays and empty objects from patch operations, preventing unnecessary API calls with empty data structures. The checks properly distinguish between arrays and objects, and handle null values correctly.

admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (3)

2-2: LGTM! Necessary import for performance optimization.

The useMemo import supports the memoized form state computations introduced later in the file.

---

20-30: LGTM! Proper typing and integration of submission state.

The isSubmitting prop is correctly typed as optional and properly integrated into the component signature, allowing the parent to control the submission loading state.

---

431-440: LGTM! Footer controls correctly implement the PR objectives.

The button states are properly derived from form state:

• Back: Always enabled (as specified)
• Cancel: Disabled when form is clean, enabled when dirty
• Apply: Disabled when form is invalid or clean, enabled when valid and dirty

The loading state correctly reflects the submission status.

admin-ui/plugins/jans-lock/components/JansLock.tsx (1)

44-54: Verify if dual loading indicators are intentional.

The current implementation shows loading state in two places during patch submission:

1. Page-level: GluuLoader blocks the entire UI when patchMutation.isPending is true (line 44, 47)
2. Button-level: The Apply button in JansLockConfiguration shows loading via isSubmitting (line 54, used at line 440 in child)

This might be intentional for layered user feedback (page-blocking + button feedback), but it could also be redundant. Consider whether:

• The page-level blocking is necessary during submission, or
• Only the button-level loading state is sufficient for better UX (allowing users to see the form while submission is in progress)

[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: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a85773e and 1e75123.

📒 Files selected for processing (1)

• admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (6 hunks)

🔇 Additional comments (3)

admin-ui/plugins/jans-lock/components/JansLockConfiguration.tsx (3)

2-2: LGTM! Clean integration of submission state.

The addition of useMemo and the isSubmitting prop correctly supports the button state management objectives outlined in the PR.

Also applies to: 23-23, 26-30

---

87-104: LGTM! Efficient use of memoized patches.

The submitForm callback correctly uses the memoized patches and updates its dependency array accordingly. The silent behavior when no patches exist (line 101) is reasonable and prevents unnecessary API calls.

---

58-60: LGTM! Cancel correctly resets the form.

The handleCancel implementation properly resets the form to its initial values using formik.resetForm(), which aligns with the PR objective for Cancel button behavior.

[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.

[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.