Skip to content

Conversation

@faisalsiddique4400
Copy link
Contributor

@faisalsiddique4400 faisalsiddique4400 commented Dec 2, 2025

feat(admin): adding uniformity in cancel and back buttons present in Auth Server(SSA, Keys) rest menus are under TS migration

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:

  • Users

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

  • New Features

    • Added Auth Server Scopes management (create/edit) and SSA pages/flows.
  • Improvements

    • Dashboard route moved to the admin path for consistency.
    • Standardized navigation across add/edit/back flows.
    • SSA form: improved expiration controls, validation, defaults, and submission flow.
  • UI/UX

    • Label alignment adjustments, new vertical divider styling, and refined commit dialog behavior.
    • JSON viewer and Keys pages: safer data handling and added form footer.
  • Other

    • Type and validation updates for SSA and viewer components.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 2, 2025

📝 Walkthrough

Walkthrough

Centralized navigation updates (new auth-server SSA/Scopes routes, HOME_DASHBOARD path change), widespread migration to useAppNavigation/ROUTES, TypeScript typing strengthens, SSA form/validation/util refactor (expiration handling), UI tweaks, and JSON viewer typing and dialog loading changes.

Changes

Cohort / File(s) Summary
Navigation Routes
admin-ui/app/helpers/navigation.ts
Updated HOME_DASHBOARD to /adm/dashboard; added AUTH_SERVER routes: AUTH_SERVER_SSA_LIST, AUTH_SERVER_SSA_ADD, AUTH_SERVER_SCOPES_LIST, AUTH_SERVER_SCOPE_ADD, AUTH_SERVER_SCOPE_EDIT.
Gluu UI Adjustments
admin-ui/app/routes/Apps/Gluu/GluuLabel.tsx, admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx, admin-ui/app/routes/Apps/Gluu/styles/applicationstyle.tsx
Adjusted label header layout and colon placement; changed order of clearing userMessage in commit dialog; added verticalDivider style.
Typed Removable Input
admin-ui/app/routes/Apps/Gluu/GluuRemovableInputRow.tsx
Made component generic TValues (default FormikValues); tightened Formik typing and keyed access to values.
Docs
admin-ui/docs/CODE_SPLITTING.md
Minor documentation and example text/formatting updates.
Keys Page & JWKS
admin-ui/plugins/auth-server/components/Configuration/Keys/Jwks/JwkListPage.tsx, .../KeysPage.tsx
Coerce missing JWKS kid to empty string for stable key generation; added GluuFormFooter to KeysPage (showBack=true, showCancel=false, showApply=false).
JSON Viewer (typed)
admin-ui/plugins/auth-server/components/JsonViewer/JsonViewer.tsx, .../JsonViewerDialog.tsx
Replaced PropTypes with TypeScript interfaces, added runtime data guard, typed props, displayName, and conditional dialog loading/render logic.
Scopes — navigation migration
admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx, .../ScopeListPage.tsx, .../hooks/useScopeActions.ts
Replaced useNavigate with useAppNavigation + ROUTES; updated navigation calls and related dependency arrays.
Sessions — handlers & types
admin-ui/plugins/auth-server/components/Sessions/SessionDetailPage.tsx, .../SessionListPage.tsx, .../types/sessionTypes.ts
Narrowed safeStringify input type; refactored table actions to memoized tableActions; removed Session index signature; adjusted selectors and TableContainer typing.
SSA — pages, types, utils, validation
admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx, .../SsaDetailPage.tsx, .../SsaListPage.tsx, .../types/ssaTypes.ts, .../utils.ts, .../validations.js (deleted), .../validations.ts (added)
Migrated SSA flows to useAppNavigation/ROUTES; added is_expirable/expirationDate to form values and types; introduced ExpirationDate and ModifiedFieldValue/ModifiedFields type alias; added getSsaInitialValues and toEpochSecondsFromDayjs; moved/rewrote Yup schema to TS; changed grant_types display to a joined string; updated dialog/loading and nonce/jwt handling in list/detail pages.
Misc — small UI/locale tweaks
admin-ui/app/locales/*/translation.json, admin-ui/app/routes/Apps/Gluu/GluuToogleRow.tsx
Updated SSA rotate_ssa translations (en/es/fr/pt); added labelStyle prop to GluuToogleRow and passed to GluuLabel.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Focus review on SSA area: SsaAddPage.tsx, SsaListPage.tsx, ssaTypes.ts, validations.ts, utils.ts (type and logic changes).
  • Verify navigation migration consistency where useAppNavigation/ROUTES replaced useNavigate.
  • Check removal of Session index signature for any downstream dynamic property usage.
  • Validate JsonViewer runtime guard, dialog isLoading behavior, and KeysPage footer placement.

Possibly related PRs

Suggested reviewers

  • syntrydy
  • duttarnab
  • moabu

Poem

🐰 I hopped through routes and typed each line,
SSA seeds sprouted, dates set to shine,
Scopes and sessions now follow the trail,
Navigation stitched like ribbon and tail,
A carrot-coded hop — hooray, that's mine!

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 title accurately captures the main objective: adding uniform behavior for Cancel and Back buttons across Admin UI forms (Auth Server SSA, Keys) during TypeScript migration.
✨ 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-auth-server

📜 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 1c384a1 and f7fdf34.

📒 Files selected for processing (9)
  • admin-ui/app/locales/en/translation.json (1 hunks)
  • admin-ui/app/locales/es/translation.json (1 hunks)
  • admin-ui/app/locales/fr/translation.json (1 hunks)
  • admin-ui/app/locales/pt/translation.json (1 hunks)
  • admin-ui/app/routes/Apps/Gluu/GluuToogleRow.tsx (2 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (5 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (8 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/utils.ts (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/validations.ts (1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 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.943Z
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.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.
📚 Learning: 2025-11-05T19:57:35.143Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.

Applied to files:

  • admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
📚 Learning: 2025-11-03T08:47:33.943Z
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.943Z
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/auth-server/components/Ssa/SsaAddPage.tsx
📚 Learning: 2025-11-06T08:23:20.948Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.

Applied to files:

  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
🧬 Code graph analysis (3)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaFormValues (26-36)
admin-ui/plugins/auth-server/components/Ssa/utils.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (2)
  • SsaFormValues (26-36)
  • ExpirationDate (24-24)
admin-ui/app/routes/Apps/Gluu/GluuToogleRow.tsx (1)
admin-ui/plugins/services/Components/Configuration/PersistenceDetail.js (1)
  • labelStyle (37-39)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: sonar scan (flex-linux-setup)
🔇 Additional comments (16)
admin-ui/app/locales/es/translation.json (1)

1096-1096: ✓ Localization update for rotate_ssa field documentation.

The Spanish translation has been appropriately updated with a clear, user-facing description. The phrasing "Alternar para habilitar o deshabilitar" correctly conveys the toggle functionality, and the notation "(Valor por defecto: true)" is consistent with similar documentation entries in this file. No issues identified.

admin-ui/app/locales/fr/translation.json (1)

1500-1500: ✓ Localization update for rotate_ssa field documentation.

The French translation has been appropriately updated with a clear, user-facing description. The phrasing "Activer/désactiver" correctly conveys the toggle functionality, and the notation "(Valeur par défaut : true)" is consistent with similar documentation entries in this file. No issues identified.

admin-ui/app/locales/pt/translation.json (1)

1590-1590: Translation update for SSA rotation documentation is clear and accurate.

The Portuguese translation effectively replaces the placeholder text with a concrete, user-facing description of the rotate_ssa field. The description accurately conveys that this setting controls whether SSA expiration rotation is enabled or disabled, with a default value of true. The phrasing is idiomatic and accessible to Portuguese-speaking users.

admin-ui/app/locales/en/translation.json (1)

1103-1103: Translation update for SSA rotation documentation is clear and user-focused.

The English translation replaces the placeholder text with a concrete, user-facing description. The "Toggle to enable or disable" phrasing is clear and aligns with standard UI documentation conventions. The description accurately captures the field's purpose and default behavior. Consistency with other translations (Portuguese, Spanish, and French, per the AI summary) demonstrates good localization practice.

admin-ui/app/routes/Apps/Gluu/GluuToogleRow.tsx (1)

18-18: LGTM! labelStyle prop addition is correctly implemented.

The new labelStyle prop is properly passed through to the GluuLabel component, enabling custom styling as shown in the relevant code snippet from PersistenceDetail.js. The implementation is straightforward and functional.

Also applies to: 29-29

admin-ui/plugins/auth-server/components/Ssa/validations.ts (2)

5-37: LGTM: Required fields and constraints now properly enforced.

The validation schema now correctly enforces required fields with .required() and .min(1) constraints on software_id, org_id, description, software_roles, and grant_types, addressing the previous review feedback. The array validations with custom tests for string-or-object types are appropriate for handling both primitive and object values.


41-62: Type safety for expirationDate field is well-established.

The expirationDate validation is properly protected by strong type contracts throughout the pipeline:

  • ExpirationDate type is explicitly defined as Dayjs | null (types/ssaTypes.ts line 24)
  • SsaFormValues.expirationDate uses this type (ssaTypes.ts line 35)
  • MUI's DatePicker with AdapterDayjs guarantees it only emits Dayjs | null values (SsaAddPage.tsx line 347)
  • The field is initialized as null (utils.ts line 13)
  • Validation includes defensive checks: value != null at line 48 and !dateValue.isValid() at line 57

No edge cases with empty strings or malformed objects can reach the validation layer due to MUI's type guarantee at the component boundary. The use of Yup.mixed() is appropriate given the field legitimately accepts Dayjs | null values.

admin-ui/plugins/auth-server/components/Ssa/utils.ts (2)

4-14: LGTM: Clean initial values function.

The getSsaInitialValues function provides sensible defaults for all SSA form fields, including the new expiration fields (is_expirable: false, expirationDate: null). The explicit type assertion on line 13 ensures TypeScript compatibility with the ExpirationDate type.


16-30: LGTM: Robust date conversion with defensive error handling.

The toEpochSecondsFromDayjs function correctly converts Dayjs objects to epoch seconds with multiple safety checks:

  • Null handling (lines 19-21)
  • Finite number validation (line 23)
  • Exception handling (lines 27-29)

The implementation is defensive and handles edge cases appropriately.

admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (3)

23-39: LGTM: Navigation refactor aligns with PR objectives.

The migration from useNavigate to useAppNavigation with route constants (ROUTES.AUTH_SERVER_SSA_ADD) improves consistency and maintainability. This keeps users within the SSA management context, consistent with the retrieved learnings.

Also applies to: 186-186


48-55: LGTM: Proper unique ID generation for MaterialTable rows.

The rowsWithId memoization adds a unique id field to each row using jti as the primary identifier, with a fallback to a composite key. This satisfies MaterialTable's requirement for unique row identifiers and handles cases where jti might be unavailable.


216-229: JsonViewerDialog already properly handles the loading state.

The JsonViewerDialog component (lines 39-48) correctly handles the case where isLoading={true} and data={null}: it renders a centered spinner with a loading message instead of attempting to display null data or an error. The conditional logic prioritizes the loading state check first, then checks for data availability, ensuring no blank or error state is shown during the fetch.

No verification needed—the refactored handleViewSsa function correctly relies on the dialog's loading state handling.

admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (4)

34-38: LGTM: Navigation migration aligns with SSA context requirements.

The migration to useAppNavigation with ROUTES.AUTH_SERVER_SSA_LIST is correct. According to the retrieved learnings, the SSA Add page should navigate to /auth-server/config/ssa (the SSA list) rather than the dashboard, keeping users in the SSA management context.

Based on learnings, SSA forms should navigate to their respective list pages.

Also applies to: 61-63, 80-83


65-100: LGTM: Expiration fields now properly integrated with Formik.

The expiration fields (is_expirable and expirationDate) are now managed as Formik fields through getSsaInitialValues() and validated by ssaValidationSchema. This resolves the previous review concern about expiration toggle/date not being included in dirty tracking:

  • Changes to is_expirable or expirationDate will now set formik.dirty = true
  • formik.resetForm() will correctly reset these fields to their initial values
  • The validation schema enforces expiration date requirements when enabled

The epoch seconds conversion on lines 92-95 correctly handles the conditional expiration payload field.


145-148: LGTM: Dirty tracking and Cancel behavior now work correctly for all fields.

The isFormDirty calculation (lines 145-148) combined with the Cancel handler (lines 394-398) now correctly handle all form state, including expiration fields:

  • formik.dirty captures changes to all Formik-managed fields, including is_expirable and expirationDate
  • Apply and Cancel buttons are properly enabled/disabled based on form state (lines 399, 402)
  • Cancel correctly resets all fields via formik.resetForm() (line 395)

This fully implements the PR's objective for uniform Cancel/Apply behavior across all fields.

Also applies to: 390-405


333-355: LGTM: Expiration date picker correctly prevents invalid dates at the UI level.

The DatePicker uses disablePast (line 348) to prevent users from selecting past dates, providing immediate feedback rather than validation errors. This is a better user experience as noted in the previous review discussion. The validation schema still provides a safety net for edge cases.

The field correctly integrates with Formik via formik.setFieldValue (line 347) and conditionally renders based on the is_expirable toggle (line 333).


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

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

@mo-auto mo-auto added area-documentation Documentation needs to change as part of issue or PR comp-admin-ui Component affected by issue or PR kind-feature Issue or PR is a new feature request labels Dec 2, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

Caution

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

⚠️ Outside diff range comments (6)
admin-ui/app/routes/Apps/Gluu/GluuRemovableInputRow.tsx (1)

107-122: Consider removing redundant PropTypes.

PropTypes are redundant now that TypeScript types are defined. While they can coexist for runtime validation, modern TypeScript projects typically rely solely on compile-time type checking.

Apply this diff to remove PropTypes:

-GluuRemovableInputRow.propTypes = {
-  label: PropTypes.string,
-  name: PropTypes.string,
-  type: PropTypes.string,
-  value: PropTypes.oneOfType([PropTypes.string, PropTypes.bool]),
-  formik: PropTypes.object,
-  required: PropTypes.bool,
-  lsize: PropTypes.number,
-  rsize: PropTypes.number,
-  handler: PropTypes.func,
-  doc_category: PropTypes.string,
-  isDirect: PropTypes.bool,
-  isBoolean: PropTypes.bool,
-  modifiedFields: PropTypes.object,
-  setModifiedFields: PropTypes.func,
-}
 export default GluuRemovableInputRow

And remove the unused import:

 import GluuToogle from 'Routes/Apps/Gluu/GluuToogle'
-import PropTypes from 'prop-types'
 import customColors from '@/customColors'
admin-ui/plugins/auth-server/components/Sessions/SessionListPage.tsx (1)

514-527: Add tableActions to the dependency array.

The renderContent callback uses tableActions (line 509) but doesn't include it in its dependency array. This violates the exhaustive-deps rule and could cause the table to display stale actions if permissions change.

Apply this diff:

   }, [
     loading,
     authenticatedSessions,
     columnState.updatedColumns,
     tableOptions,
     handleDetailPanel,
     TableContainer,
     tableKey,
     searchParams,
     isFilterApplied,
     filterState.pattern,
     filterState.searchFilter,
     t,
+    tableActions,
   ])
admin-ui/plugins/auth-server/components/Ssa/SsaDetailPage.tsx (1)

88-93: Defensively handle possible missing grant_types before calling join

row.ssa.grant_types.join(', ') will throw if grant_types is ever undefined/null. Unless the DTO guarantees this array is always present, this is a potential runtime error.

Consider a safer variant:

-            value={row.ssa.grant_types.join(', ')}
+            value={(row.ssa.grant_types && row.ssa.grant_types.length > 0)
+              ? row.ssa.grant_types.join(', ')
+              : ''}

(or use optional chaining with a fallback), so the detail page remains robust if the field is absent.

admin-ui/app/helpers/navigation.ts (1)

85-93: navigateBack silently does nothing when history is empty and no fallback is provided.

When window.history.length <= 1 and fallbackRoute is undefined, the function returns without navigating anywhere. This could leave users stuck. Consider making fallbackRoute required or defaulting to ROUTES.HOME_DASHBOARD.

   const navigateBack = useCallback(
-    (fallbackRoute?: string): void => {
+    (fallbackRoute: string = ROUTES.HOME_DASHBOARD): void => {
       if (window.history.length > 1) {
         navigate(-1)
-      } else if (fallbackRoute) {
+      } else {
         navigateToRoute(fallbackRoute)
       }
     },
     [navigate, navigateToRoute],
   )

Based on learnings, callers should provide context-specific fallbacks (e.g., SSA pages fall back to /auth-server/config/ssa), but having a default ensures navigation always occurs.

admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (1)

168-173: Potential state inconsistency in toggleSsaDialog.

The toggle function clears jwtData only when the dialog is currently open (ssaDialogOpen is true before toggling). However, the condition checks the value before the toggle happens:

if (ssaDialogOpen) {  // This is the OLD value
  setJwtData(null)
}

This means jwtData is cleared when closing the dialog, which is correct. But if this function is ever called to open the dialog (when ssaDialogOpen is false), it won't clear stale data. Currently, handleViewSsa handles this by clearing data before opening, so it's safe, but the logic in toggleSsaDialog could be clearer:

   const toggleSsaDialog = (): void => {
-    setSsaDialogOpen(!ssaDialogOpen)
-    if (ssaDialogOpen) {
+    const wasOpen = ssaDialogOpen
+    setSsaDialogOpen(!wasOpen)
+    if (wasOpen) {
       setJwtData(null)
     }
   }

This is minor since current usage is correct, but improves readability.

admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (1)

69-86: Formik + centralized validation look good; consider i18n for expiration toasts

The switch to:

  • useFormik<SsaFormValues> with initialValues={getSsaInitialValues()} and validationSchema={ssaValidationSchema}
  • centralized epoch conversion via toEpochSecondsFromDayjs in openCommitDialog
  • submitForm delegating to createSsaMutation.mutateAsync and audit logging

is clean and aligns the form with the shared utilities/types for SSA. That part looks solid.

Two minor follow-ups:

  1. Manual expiration validation vs schema
    Expiration rules (required + future date when isExpirable) are enforced imperatively in onSubmit. That’s fine, but if you plan to reuse this pattern elsewhere, consider pushing those rules into the validation schema so everything is expressed in one place and remains type-aligned with SsaFormValues.

  2. Hard-coded error messages should use i18n
    These toasts:

    dispatch(updateToast(true, 'error', 'Please select an expiration date'))
    dispatch(updateToast(true, 'error', 'Expiration date must be in the future'))

    bypass t(...) and will not be localized. Prefer introducing translation keys and using t('...') here (and, if necessary, wiring those keys into your toast slice) so error messaging is consistent with the rest of the UI.

    For example (keys are illustrative):

  •  if (isExpirable && !expirationDate) {
    
  •    dispatch(updateToast(true, 'error', 'Please select an expiration date'))
    
  •  if (isExpirable && !expirationDate) {
    
  •    dispatch(updateToast(true, 'error', t('messages.expiration_date_required')))
       return
     }
    
  •  if (isExpirable && expirationDate && expirationDate.isBefore(dayjs())) {
    
  •    dispatch(updateToast(true, 'error', 'Expiration date must be in the future'))
    
  •  if (isExpirable && expirationDate && expirationDate.isBefore(dayjs())) {
    
  •    dispatch(updateToast(true, 'error', t('messages.expiration_date_in_future')))
       return
     }
    
    
    (You can adjust the actual keys/texts to match your translation files.)
    
    
    
    
    
    
    

Also applies to: 101-105, 155-177

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e4ece9 and 7db1980.

📒 Files selected for processing (21)
  • admin-ui/app/helpers/navigation.ts (2 hunks)
  • admin-ui/app/routes/Apps/Gluu/GluuLabel.tsx (1 hunks)
  • admin-ui/app/routes/Apps/Gluu/GluuRemovableInputRow.tsx (3 hunks)
  • admin-ui/docs/CODE_SPLITTING.md (7 hunks)
  • admin-ui/plugins/auth-server/components/Configuration/Keys/Jwks/JwkListPage.tsx (2 hunks)
  • admin-ui/plugins/auth-server/components/Configuration/Keys/KeysPage.tsx (2 hunks)
  • admin-ui/plugins/auth-server/components/JsonViewer/JsonViewer.tsx (2 hunks)
  • admin-ui/plugins/auth-server/components/JsonViewer/JsonViewerDialog.tsx (3 hunks)
  • admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx (3 hunks)
  • admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx (3 hunks)
  • admin-ui/plugins/auth-server/components/Scopes/hooks/useScopeActions.ts (3 hunks)
  • admin-ui/plugins/auth-server/components/Sessions/SessionDetailPage.tsx (1 hunks)
  • admin-ui/plugins/auth-server/components/Sessions/SessionListPage.tsx (8 hunks)
  • admin-ui/plugins/auth-server/components/Sessions/types/sessionTypes.ts (0 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (6 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaDetailPage.tsx (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (7 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/utils.ts (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/validations.js (0 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/validations.ts (1 hunks)
💤 Files with no reviewable changes (2)
  • admin-ui/plugins/auth-server/components/Sessions/types/sessionTypes.ts
  • admin-ui/plugins/auth-server/components/Ssa/validations.js
🧰 Additional context used
🧠 Learnings (5)
📓 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.943Z
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.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.
📚 Learning: 2025-11-06T08:23:20.948Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.

Applied to files:

  • admin-ui/docs/CODE_SPLITTING.md
  • admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
  • admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx
  • admin-ui/app/helpers/navigation.ts
📚 Learning: 2025-11-05T19:57:35.143Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.

Applied to files:

  • admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
  • admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx
  • admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx
  • admin-ui/app/helpers/navigation.ts
📚 Learning: 2025-11-03T08:47:33.943Z
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.943Z
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/auth-server/components/Scopes/ScopeForm.tsx
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
  • admin-ui/plugins/auth-server/components/Configuration/Keys/KeysPage.tsx
📚 Learning: 2025-11-07T12:55:26.241Z
Learnt from: kdhttps
Repo: GluuFederation/flex PR: 2378
File: admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx:93-104
Timestamp: 2025-11-07T12:55:26.241Z
Learning: In the Cedarling configuration feature (admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx), the sync role to scopes mappings operation depends on the `auiPolicyStoreUrl`. The backend fetches content from this URL and syncs roles based on the response. Therefore, the audit log for the sync operation should include the `auiPolicyStoreUrl` in its payload to provide proper audit context.

Applied to files:

  • admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx
🧬 Code graph analysis (11)
admin-ui/plugins/auth-server/components/Scopes/hooks/useScopeActions.ts (1)
admin-ui/app/helpers/navigation.ts (2)
  • useAppNavigation (75-104)
  • ROUTES (106-106)
admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx (1)
admin-ui/app/helpers/navigation.ts (2)
  • useAppNavigation (75-104)
  • ROUTES (106-106)
admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx (3)
admin-ui/app/helpers/navigation.ts (2)
  • useAppNavigation (75-104)
  • ROUTES (106-106)
admin-ui/plugins/auth-server/components/Scopes/types/index.ts (1)
  • ScopeTableRow (33-33)
admin-ui/plugins/auth-server/components/Scopes/types/componentTypes.ts (1)
  • ScopeTableRow (24-28)
admin-ui/plugins/auth-server/components/Ssa/utils.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaFormValues (24-32)
admin-ui/plugins/auth-server/components/JsonViewer/JsonViewer.tsx (1)
admin-ui/plugins/auth-server/redux/sagas/SsaSaga.js (1)
  • jsonData (135-135)
admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (3)
admin-ui/app/helpers/navigation.ts (2)
  • useAppNavigation (75-104)
  • ROUTES (106-106)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaData (14-18)
admin-ui/plugins/auth-server/components/Ssa/types/index.ts (1)
  • SsaData (3-3)
admin-ui/plugins/auth-server/components/Sessions/SessionListPage.tsx (3)
admin-ui/plugins/auth-server/components/Sessions/types/sessionTypes.ts (1)
  • Session (14-23)
admin-ui/plugins/auth-server/components/Sessions/types/index.ts (1)
  • Session (3-3)
admin-ui/app/customColors.ts (1)
  • customColors (4-25)
admin-ui/plugins/auth-server/components/JsonViewer/JsonViewerDialog.tsx (1)
admin-ui/app/customColors.ts (1)
  • customColors (4-25)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (2)
admin-ui/plugins/schema/components/types/AttributeListPage.types.ts (1)
  • ModifiedFieldValue (9-16)
admin-ui/plugins/auth-server/components/Ssa/types/index.ts (1)
  • ModifiedFields (10-10)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaFormValues (24-32)
admin-ui/plugins/auth-server/components/Sessions/SessionDetailPage.tsx (2)
admin-ui/plugins/auth-server/components/Sessions/types/sessionTypes.ts (1)
  • SessionDetailPageProps (35-37)
admin-ui/plugins/auth-server/components/Sessions/types/index.ts (1)
  • SessionDetailPageProps (5-5)
🔇 Additional comments (26)
admin-ui/plugins/auth-server/components/Sessions/SessionDetailPage.tsx (1)

43-48: LGTM! Type safety improvement.

The refinement from any to a specific union type improves type safety and aligns with TypeScript best practices. The new signature correctly reflects the actual usage at lines 108 and 119.

admin-ui/plugins/auth-server/components/Configuration/Keys/Jwks/JwkListPage.tsx (1)

9-11: Stable key helper improves type-safety and readability

generateStableKey taking a non-optional kid and handling the empty-string case keeps the implementation simple while making the type contract explicit. This looks good.

admin-ui/app/routes/Apps/Gluu/GluuRemovableInputRow.tsx (1)

15-47: LGTM! Good TypeScript generic implementation.

The addition of the generic type parameter TValues appropriately improves type safety for Formik integration while maintaining backward compatibility through the default type parameter.

admin-ui/plugins/auth-server/components/Sessions/SessionListPage.tsx (6)

1-8: LGTM! Type safety improvements.

The addition of explicit type imports (SyntheticEvent, Action) and the migration from any to AuditRootState improve type safety throughout the component.

Also applies to: 11-11, 46-47, 57-57


73-73: LGTM! Improved state typing.

Replacing any with AuditRootState provides proper type checking for the auth state selector.


389-394: LGTM! Correct event typing.

The signature now properly matches Material-UI Autocomplete's onChange prop expectations with SyntheticEvent.


451-454: LGTM! Better component typing.

Using React.ComponentProps<typeof Paper> provides accurate type checking for the Paper container props.


478-478: LGTM! Consistent i18n usage.

Using the translation key ensures the loading message is properly internationalized.


509-509: LGTM! Consistent with tableActions refactor.

The MaterialTable now correctly uses the new memoized tableActions array.

admin-ui/plugins/auth-server/components/Configuration/Keys/KeysPage.tsx (1)

12-44: GluuFormFooter integration on Keys page looks consistent

Adding GluuFormFooter with only showBack enabled matches this read‑only configuration page and aligns with the shared footer pattern; no issues spotted here.

admin-ui/docs/CODE_SPLITTING.md (1)

11-133: Updated code‑splitting docs are clear and aligned with current routing

The examples (lazy routes, plugin/component loading, /adm/dashboard route, analyze/build commands) are coherent and match the current navigation patterns; nothing blocking here.

admin-ui/plugins/auth-server/components/Scopes/ScopeForm.tsx (1)

39-40: Back/Cancel/Apply wiring in ScopeForm aligns with centralized navigation and dirty‑state rules

Using useAppNavigation with navigateBack(ROUTES.AUTH_SERVER_SCOPES_LIST) ensures Back goes to the previous page when possible and otherwise falls back to the scopes list, matching the “redirect to listing screen” behavior adopted in other forms. Footer props (disableCancel / disableApply based on hasActualChanges and Formik state) correctly implement the desired Back/Cancel/Apply semantics without navigation side effects.

Based on learnings, this matches the pattern used for SSA and UserForm back‑navigation.

Also applies to: 61-62, 159-162, 672-687

admin-ui/plugins/auth-server/components/Scopes/hooks/useScopeActions.ts (1)

7-8: Scope navigation hook now consistently uses centralized ROUTES

Switching navigateToScopeList/Add/Edit to navigateToRoute(ROUTES.AUTH_SERVER_*) via useAppNavigation is clean and keeps navigation logic centralized; dependency arrays are correct and no regressions are apparent.

Also applies to: 27-28, 83-96

admin-ui/plugins/auth-server/components/Scopes/ScopeListPage.tsx (1)

47-48: Centralized navigation in ScopeListPage is correct and guarded

Using useAppNavigation with ROUTES.AUTH_SERVER_SCOPE_ADD / ROUTES.AUTH_SERVER_SCOPE_EDIT(row.inum) brings this list page in line with the new navigation helper, and the row.inum guard on edit avoids navigating to an invalid route when the key is missing. Looks good.

Also applies to: 81-84, 314-325

admin-ui/plugins/auth-server/components/Ssa/utils.ts (2)

1-12: LGTM!

Good TypeScript migration. The explicit return type SsaFormValues ensures type safety, and the initial values correctly match all fields defined in the SsaFormValues interface.


15-27: LGTM!

The function properly handles edge cases: null input, invalid dates, and exceptions. The explicit return type number | null is clear.

admin-ui/plugins/auth-server/components/JsonViewer/JsonViewer.tsx (1)

7-21: LGTM!

Clean TypeScript migration with well-defined props interface and sensible defaults. The removal of PropTypes in favor of TypeScript interfaces improves type safety.

admin-ui/app/helpers/navigation.ts (2)

34-41: LGTM!

The new Auth Server routes are well-structured with proper URL encoding for dynamic parameters. The naming convention is consistent with existing routes.


5-6: Dashboard path migration is complete.

All references to the old /home/dashboard path have been successfully updated to /adm/dashboard. No remaining references to the old path were found in the codebase.

admin-ui/plugins/auth-server/components/JsonViewer/JsonViewerDialog.tsx (2)

8-26: LGTM!

Clean TypeScript interface with appropriate optional props and sensible defaults. The component signature is clear and well-typed.


39-48: LGTM!

The conditional rendering correctly handles all states: loading spinner when fetching, JsonViewer when data is available, and nothing when neither condition is met. This aligns well with the loading state integration mentioned in the PR objectives.

admin-ui/plugins/auth-server/components/Ssa/SsaListPage.tsx (4)

39-39: LGTM!

Good adoption of the centralized navigation hook. This aligns with the PR objective of consistent navigation behavior.


145-159: LGTM!

Disabling actions while getSsaJwtMutation.isPending prevents users from triggering multiple concurrent JWT fetches, which is good UX.


206-218: LGTM!

The refactored handleViewSsa provides good UX:

  1. Clears previous data immediately
  2. Opens dialog with loading state
  3. Populates data on success or closes dialog on error

The error handling properly closes the dialog and shows a toast, preventing users from seeing a stuck loading state.


296-306: LGTM!

The JsonViewerDialog correctly receives the isLoading prop tied to the mutation state, providing immediate feedback to users while the JWT is being fetched.

admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (1)

36-41: Navigation refactor to useAppNavigation and SSA list route looks correct

Using useAppNavigation with:

  • handleNavigateBacknavigateBack(ROUTES.AUTH_SERVER_SSA_LIST)
  • post-create redirect → navigateToRoute(ROUTES.AUTH_SERVER_SSA_LIST) in the createSsaMutation.isSuccess effect

keeps the user within the SSA management context and provides a clear fallback to the SSA list rather than an unrelated screen. This matches the prior requirement that the SSA Add Back behavior should fall back to /auth-server/config/ssa when history is unavailable. Based on learnings, this is the expected behavior for this page.

No changes needed here.

Also applies to: 65-67, 90-95

Copy link
Contributor

@duttarnab duttarnab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Apply button not working in SSA
  2. Cancel button not working for Is Expirable? field in SSA page

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7db1980 and a3df017.

📒 Files selected for processing (6)
  • admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx (1 hunks)
  • admin-ui/app/routes/Apps/Gluu/styles/applicationstyle.tsx (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (5 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (3 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/utils.ts (1 hunks)
  • admin-ui/plugins/auth-server/components/Ssa/validations.ts (1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 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.943Z
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.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.
📚 Learning: 2025-11-05T19:57:35.143Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.

Applied to files:

  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
📚 Learning: 2025-11-06T08:23:20.948Z
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.

Applied to files:

  • admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx
🧬 Code graph analysis (5)
admin-ui/app/routes/Apps/Gluu/styles/applicationstyle.tsx (1)
admin-ui/app/customColors.ts (1)
  • customColors (4-25)
admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (7)
admin-ui/app/helpers/navigation.ts (1)
  • useAppNavigation (75-104)
admin-ui/plugins/auth-server/components/Ssa/types/index.ts (2)
  • SsaFormValues (5-5)
  • SsaCreatePayload (6-6)
admin-ui/plugins/auth-server/components/Ssa/utils.ts (2)
  • getSsaInitialValues (4-14)
  • toEpochSecondsFromDayjs (17-30)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)
  • ssaValidationSchema (5-31)
admin-ui/plugins/admin/components/Webhook/WebhookForm.js (1)
  • openCommitDialog (84-84)
admin-ui/plugins/auth-server/components/Ssa/constants.ts (2)
  • FORM_LAYOUT (14-20)
  • GRANT_TYPES (1-8)
admin-ui/plugins/auth-server/redux/audit/Resources.js (2)
  • SSA (6-6)
  • SSA (6-6)
admin-ui/plugins/auth-server/components/Ssa/utils.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (2)
  • SsaFormValues (26-36)
  • ExpirationDate (24-24)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaFormValues (26-36)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (2)
admin-ui/plugins/auth-server/components/Ssa/types/index.ts (2)
  • ExpirationDate (11-11)
  • ModifiedFields (10-10)
admin-ui/plugins/schema/components/types/AttributeListPage.types.ts (1)
  • ModifiedFieldValue (9-16)
🔇 Additional comments (8)
admin-ui/app/routes/Apps/Gluu/styles/applicationstyle.tsx (1)

44-47: LGTM! Clean style addition for vertical separation.

The verticalDivider style is well-formed and uses the existing customColors.lightGray constant. This aligns with the PR's goal of improving button layout consistency.

admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx (1)

87-91: LGTM! Good refactoring—consolidates cleanup in one place.

Moving setUserMessage('') to occur after onCloseModal() ensures the message remains available throughout the close flow and centralizes cleanup logic. The existing useEffect (lines 75-77) already clears the message when the modal reopens, preventing unintended persistence.

admin-ui/plugins/auth-server/components/Ssa/utils.ts (1)

1-30: LGTM!

The utility functions are well-typed with explicit return types, proper null handling in toEpochSecondsFromDayjs, and the initial values align with the updated SsaFormValues interface including the new is_expirable and expirationDate fields.

admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (2)

24-36: LGTM!

The new ExpirationDate type alias and extended SsaFormValues interface properly support the expiration date functionality. The types align well with the validation schema and utility functions.


62-64: Type scope is appropriate.

ModifiedFieldValue is kept as a private type (not exported), limiting its scope to SSA-specific usage. This addresses the previous concern about divergent definitions across modules.

admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx (3)

61-63: Correct fallback route for SSA context.

The Back button correctly falls back to ROUTES.AUTH_SERVER_SSA_LIST, keeping users in the SSA management context. This aligns with the learned pattern from previous PRs.


142-145: Expiration fields now properly tracked via Formik.

Since is_expirable and expirationDate are now Formik-managed fields, formik.dirty correctly reflects changes to these values, and formik.resetForm() in the Cancel handler properly resets them. This addresses the previous review concern about expiration state not being part of dirty tracking.


381-396: Form footer logic correctly implements the PR objectives.

The Cancel/Apply button behavior aligns with the stated requirements:

  • Cancel resets form state and is disabled when no changes exist
  • Apply triggers form submission and is disabled when form is invalid, unchanged, or submitting
  • Back navigates to the appropriate context-specific route

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)

5-13: Confirm mandatory SSA fields and avoid hiding schema/type mismatches

Right now only software_id and description are required; org_id, software_roles, and grant_types are effectively optional/empty, even though SsaFormValues types them as always present. Please double‑check the SSA business rules: if those fields must be provided and non‑empty, add .required() for org_id and .min(1, ...) on the arrays, or relax the TS type instead so UI validation and types stay in sync. Also, the as Yup.ObjectSchema<SsaFormValues> cast can mask future drift (e.g., adding a field to SsaFormValues but forgetting to update the schema); consider typing the constant instead of casting, or using satisfies to keep compiler checks.

-  org_id: Yup.string(),
+  org_id: Yup.string().required('Organization ID is required'),
@@
-  software_roles: Yup.array().of(Yup.string()),
+  software_roles: Yup.array().of(Yup.string()).min(1, 'At least one role is required'),
@@
-  grant_types: Yup.array().of(Yup.string()),
+  grant_types: Yup.array().of(Yup.string()).min(1, 'At least one grant type is required'),
📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a3df017 and 1c384a1.

📒 Files selected for processing (1)
  • admin-ui/plugins/auth-server/components/Ssa/validations.ts (1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 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.943Z
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.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2415
File: admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx:148-153
Timestamp: 2025-11-05T19:57:35.143Z
Learning: In the SSA Add page (admin-ui/plugins/auth-server/components/Ssa/SsaAddPage.tsx), the Back button should fall back to '/auth-server/config/ssa' when browser history is unavailable, not '/home/dashboard', as this keeps users in the SSA management context.
Learnt from: faisalsiddique4400
Repo: GluuFederation/flex PR: 2418
File: admin-ui/plugins/user-management/components/UserForm.tsx:290-297
Timestamp: 2025-11-06T08:23:20.948Z
Learning: In the UserForm component (admin-ui/plugins/user-management/components/UserForm.tsx), the Back button should fall back to '/user/usersmanagement' when browser history is unavailable, not '/home/dashboard', as this keeps users in the user management context. This aligns with the new requirement that users should be redirected to the respective listing screen of the component rather than the dashboard.
🧬 Code graph analysis (1)
admin-ui/plugins/auth-server/components/Ssa/validations.ts (1)
admin-ui/plugins/auth-server/components/Ssa/types/ssaTypes.ts (1)
  • SsaFormValues (26-36)

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 4, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-documentation Documentation needs to change as part of issue or PR comp-admin-ui Component affected by issue or PR kind-feature Issue or PR is a new feature request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants