Add support for handling groups tier limit reached

[Lakshan-Banneheke]

Purpose

This is to Add support for handling groups tier limit reached

This follows the same approach done for applications, sub organizations, connections

Related Issues

• N/A

Related PRs

• N/A

Checklist

• e2e cypress tests locally verified. (for internal contributers)
• Manual test round performed and verified.
• UX/UI review done on the final implementation.
• Documentation provided. (Add links if there are any)
• Relevant backend changes deployed and verified
• Unit tests provided. (Add links if there are any)
• Integration tests provided. (Add links if there are any)

Security checks

• Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines
• Ran FindSecurityBugs plugin and verified report
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets

Developer Checklist (Mandatory)

• Complete the Developer Checklist in the related product-is issue to track any behavioral change or migration impact.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new changesets entry coordinates synchronized patch releases. The create-group wizard now intercepts 403 responses with tier limit errors, displays a modal with localized text, and prevents wizard closure. Supporting error constants and i18n translations are added.

Changes

Cohort / File(s)	Summary
Changesets .changeset/witty-teeth-vanish.md	Introduces synchronized patch releases for @wso2is/admin.groups.v1, @wso2is/console, and @wso2is/i18n to document tier limit support.
Constants features/admin.groups.v1/constants/group-constants.ts	Adds ERROR_CREATE_LIMIT_REACHED constant with error identifier ASG-FG-API-60002 and localization keys for tier limit error scenarios.
UI Components features/admin.groups.v1/components/wizard/create-group-wizard.tsx	Implements tier limit error handling by detecting 403 responses, displaying TierLimitReachErrorModal with localized content, and preventing wizard closure when limit is reached.
Internationalization modules/i18n/src/models/namespaces/groups-ns.ts, modules/i18n/src/translations/en-US/portals/groups.ts	Adds TypeScript interface definitions and English translations for tier limit error notifications including empty-state UI text with action links and titles.

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding support for handling groups tier limit reached, which aligns with the core modifications across wizard components, constants, and translations.
Description check	✅ Passed	The description follows the repository template with Purpose, Related Issues, Related PRs, and Checklist sections included. However, all verification and testing checkboxes remain unchecked, and the mandatory Developer Checklist is incomplete.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Changeset Required	✅ Passed	The pull request includes a properly formatted changeset file documenting changes to affected packages with appropriate version updates and clear description.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Review ran into problems

🔥 Problems

Timed out fetching pipeline failures after 30000ms

---

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

_{Review rate limit: 0/1 reviews remaining, refill in 60 minutes.}

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.05%. Comparing base (4e29055) to head (237eda6).
⚠️ Report is 566 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #10215   +/-   ##
=======================================
  Coverage   56.05%   56.05%           
=======================================
  Files          42       42           
  Lines        1024     1024           
  Branches      254      254           
=======================================
  Hits          574      574           
  Misses        416      416           
  Partials       34       34           

Flag	Coverage Δ
@wso2is/core	56.05% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In `@features/admin.groups.v1/components/wizard/create-group-wizard.tsx`:
- Around line 603-611: The TierLimitReachErrorModal invocation passes
actionLabel and header props, but the component only destructures { description,
message, openModal, handleModalClose } and ignores those two props; remove the
actionLabel and header assignments from the TierLimitReachErrorModal JSX in
create-group-wizard.tsx (i.e., drop the actionLabel={...} and header={...}
props) so the callsite matches the component's actual API and avoid passing
unused props.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: df4bd7c8-86db-45b4-9f56-061d1411da59

📥 Commits

Reviewing files that changed from the base of the PR and between 32442de and 237eda6.

📒 Files selected for processing (5)

• .changeset/witty-teeth-vanish.md
• features/admin.groups.v1/components/wizard/create-group-wizard.tsx
• features/admin.groups.v1/constants/group-constants.ts
• modules/i18n/src/models/namespaces/groups-ns.ts
• modules/i18n/src/translations/en-US/portals/groups.ts

[pavinduLakshan]

Since the tierLimitReached modal is going to be soon used across multiple UI components with the introduction of the trial account concept, implementing this separately in each UI page will lead to duplication and make maintenance harder.

A better approach would be to centralize the modal at a higher level, such as App.tsx or another appropriate root component, and control its visibility through a global state mechanism like Redux or React Context. With this in place, triggering the modal becomes a simple state update or dispatch call, for example directly from a catch block, without needing to replicate modal logic across components.

PS: An AI tool might be helpful in achieving this ;)

[Lakshan-Banneheke]

Since the tierLimitReached modal is going to be soon used across multiple UI components with the introduction of the trial account concept, implementing this separately in each UI page will lead to duplication and make maintenance harder.

A better approach would be to centralize the modal at a higher level, such as App.tsx or another appropriate root component, and control its visibility through a global state mechanism like Redux or React Context. With this in place, triggering the modal becomes a simple state update or dispatch call, for example directly from a catch block, without needing to replicate modal logic across components.

PS: An AI tool might be helpful in achieving this ;)

Thanks for the comment Pavindu. I agree that centralizing this would be a better approach. However, currently we already have this mechanism in 10 pages and different components get different error codes depending on the resource (This in itself is a problem which we need to improve and unify to a single error code :) ). Due to that, I think we will need to atleast retain the "if" condition logic in each component even if we move the other logic to a centralized location at present.

Additionally, with the new effort we will only be introducing this to 3 new pages, so there will not be a significant increase in the usage of the tierLimitReached modal, and with the time constraints, it will be a bit difficult to implement the centralized mechanism at present. (The timeline is to onboard this to Dev to all the new pages by EOD today).

However, I completely agree that the approach you are suggesting is a better approach. Shall we create an issue for this and track as an improvement?

[pavinduLakshan]

Since the tierLimitReached modal is going to be soon used across multiple UI components with the introduction of the trial account concept, implementing this separately in each UI page will lead to duplication and make maintenance harder.

A better approach would be to centralize the modal at a higher level, such as App.tsx or another appropriate root component, and control its visibility through a global state mechanism like Redux or React Context. With this in place, triggering the modal becomes a simple state update or dispatch call, for example directly from a catch block, without needing to replicate modal logic across components.

@coderabbitai create an issue to track this.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll create a GitHub issue to track the centralization of TierLimitReachErrorModal right away.

---

🏁 Script executed:

#!/bin/bash
gh issue create \
  --repo wso2/identity-apps \
  --title "Centralize TierLimitReachErrorModal using global state (Redux/React Context)" \
  --body "## Summary

Currently, \`TierLimitReachErrorModal\` is implemented independently in each UI page/component (already present in ~10 pages). As the trial account concept expands, this modal will be introduced to even more components, leading to duplicated logic and increased maintenance overhead.

## Problem

- The modal state (\`tierLimitReached\`, open/close handlers, localized strings) is replicated across every component that needs to show it.
- Each resource returns different error codes, making the conditional logic per-component unavoidable in its current form.
- As more pages adopt this pattern, keeping the implementations consistent becomes increasingly difficult.

## Proposed Improvement

Centralize the \`TierLimitReachErrorModal\` at a higher-level component such as \`App.tsx\` (or another appropriate root component) and control its visibility through a global state mechanism — Redux or React Context.

With this in place:
- Triggering the modal becomes a simple dispatch call or context update directly from a \`catch\` block in any component.
- No need to replicate modal JSX, state variables, or close handlers across components.
- Maintenance and future changes are isolated to a single location.

## References

- Related PR: https://github.com/wso2/identity-apps/pull/10215
- Discussion: https://github.com/wso2/identity-apps/pull/10215#discussion_r2077500000

## Requested by

`@pavinduLakshan`" \
  --assignee pavinduLakshan

Length of output: 51

---

@pavinduLakshan: The GitHub issue has been created and assigned to you — you can track it at #10224.

It captures the proposed improvement to centralize TierLimitReachErrorModal at a root-level component (e.g., App.tsx) and control its visibility via Redux or React Context, along with a backlink to this PR and discussion.

---

🧠 Learnings used

Learnt from: Lakshan-Banneheke
Repo: wso2/identity-apps PR: 10215
File: features/admin.groups.v1/components/wizard/create-group-wizard.tsx:603-611
Timestamp: 2026-04-29T15:34:07.828Z
Learning: In wso2/identity-apps, the `TierLimitReachErrorModal` component (from `wso2is/admin.core.v1/components/modals`) is invoked with `actionLabel` and `header` props even if the current implementation does not consume them, in order to maintain consistency with other call sites and allow for future extensibility. Do not flag these as unused props in code reviews.

---

Learnt from: Lakshan-Banneheke
Repo: wso2/identity-apps PR: 9920
File: apps/console/src/app.tsx:249-269
Timestamp: 2026-03-25T05:29:40.258Z
Learning: In `apps/console/src/app.tsx`, the `useEffect` that calls `activateTrial()` is intentionally decoupled from the onboarding flow (`shouldShowOnboarding`). Trial activation is a tenant-level concern that should fire independently of whether the user goes through onboarding. The primary guard is the `isTrialActivationEnabled` feature flag (`tenants.trialActivation`, disabled by default) and the `trialActivationAttempted` ref. Do not suggest gating this effect on `shouldShowOnboarding` or the onboarding route.

---

Learnt from: CR
Repo: wso2/identity-apps PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-02-19T09:09:00.768Z
Learning: Applies to **/*.{ts,tsx} : Use Redux only for app-wide state and alerts (`dispatch(addAlert(...))`); do not use Redux for feature-internal state

---

Learnt from: CR
Repo: wso2/identity-apps PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-02-19T09:09:00.768Z
Learning: Applies to features/**/*.{ts,tsx} : Dispatch error notifications via Redux with `dispatch(addAlert({ description, level: AlertLevels.ERROR, message }))` in catch blocks

---

Learnt from: CR
Repo: wso2/identity-apps PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-02-19T09:09:00.768Z
Learning: Applies to features/**/components/shared/**/*.{ts,tsx} : Reusable UI components scoped to a feature should be in `components/shared/` within that feature