feat(my-org): invitation roles API types, constants and locales [1/2] - #456
feat(my-org): invitation roles API types, constants and locales [1/2]#456grandmaester wants to merge 2 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughInvitation role queries are now scoped by invitation ID. Member-management service and modal contracts use invitation-specific roles and loading state. English and Japanese error messages cover role-fetch failures, and test mocks use the renamed fields. ChangesInvitation role query and service contract
Invitation role view integration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
| export const memberManagementQueryKeys = { | ||
| all: ['member-management'] as const, | ||
| invitations: () => [...memberManagementQueryKeys.all, 'invitations'] as const, | ||
| roles: () => [...memberManagementQueryKeys.all, 'roles'] as const, |
There was a problem hiding this comment.
hope this is verified and not used anywhere else?
…/invitation-roles-api-setup
2 participants
Summary
Lays the type, constant and locale groundwork for consuming the new
GET /my-org/member-invitations/{invitation_id}/rolesendpoint, and updates the member management view to pass the invitation's roles down to the details modal.This is part 1 of 2. It is the base of a stacked pair and is not independently mergeable — see the callout under What.
Why
The invitation details modal currently resolves a pending invitation's role names by fetching the tenant's roles list and intersecting it client-side against the role IDs on the invitation. That approach has two problems:
MAX_ROLES_AVAILABLE_FOR_ASSIGNMENT = 100. Any role beyond the first 100 could not be resolved, and the modal rendered the raw role ID instead of the name — with no indication anything was missing.The API team added a dedicated sub-resource for this (see References). Per AEP review, role metadata is not embedded in the invitation response; the roles are a sub-resource with their own endpoint. This PR renames and reshapes the contracts to match that model so the hook/service work in part 2 can land against stable types.
What
Query keys —
memberManagementQueryKeys.roles()becomesinvitationRoles(id), keyed per invitation so each invitation's roles cache independently:rolesSearch(term)is untouched — the create/assign-roles modals still use the paginated role search, which is a different concern.SDK response type — re-exports
GetMemberInvitationRolesResponseContentfrom@auth0/myorganization-jsso consumers do not reach into the SDK namespace directly.Service options —
enableRolesList?: booleanbecomesinvitationRolesId?: string | null. The old flag only gated whether to bulk-fetch; the new field doubles as the request parameter and the enablement gate (omit it and no request fires).Hook result —
availableRolesis removed andisFetchingAvailableRolesbecomes:availableRoleshad exactly one consumer — the details modal — so it is fully dead once the modal readsrolesinstead.rolesQueryonMemberManagementServiceResultbecomesinvitationRolesQuery.Details modal props —
availableRoles?: Role[]becomesroles?: Role[]plusisLoadingRoles?: boolean. The rename is deliberate: the prop no longer carries "roles you could pick from", it carries "this invitation's roles".Constant removed —
MAX_ROLES_AVAILABLE_FOR_ASSIGNMENTis deleted. Nothing needs a bulk cap once roles arrive scoped to the invitation.MAX_ROLES_PER_REQUEST,MAX_ROLES_PER_MEMBERandDEFAULT_ROLES_PAGE_SIZEare unchanged.Locales — adds
member_management.invitation.error.fetch_roles_failedto the typed custom-message interface,en-US.jsonandja.json.Important
This PR fails
packages/reacttypecheck on its own (26 errors), by design. It removes type members and a constant whose consumers are updated in part 2.packages/coretypechecks clean. Merge part 2 (#457) into this branch first, then this branch intofeat/my-org-ea-branch. Do not merge this alone.Packages
packages/corepackages/reactexamplesReferences
Testing
Verified at this commit:
tsc --noEmit -p packages/core— cleanpackages/coretest suite — 26 files, 1090 tests passingpackages/reacttypecheck — 26 errors, all consumers of the members removed here, resolved by part 2 (see callout above)The one test file touched here is a harness update, not new coverage:
organization-member-management.test.tsxrenames two required fields on the mocked hook result (availableRoles→invitationRoles,isFetchingAvailableRoles→isFetchingInvitationRoles). Those fields are mandatory onUseOrganizationMemberManagementResult, which the view props extend, so the file would not compile without them. All new behavioural coverage is in part 2.One incidental diff: the
OrganizationInvitationTabPropsinterface header inorganization-invitation-table-types.tsis reformatted. That block was not prettier-clean before;prettier --writenormalized it while formatting the real change in the same file. No semantic change.Checklist
useOrganizationMemberManagementis publicly exported, so removingavailableRolesand renamingisFetchingAvailableRoleschanges its return type. This was a deliberate call rather than keeping the old fields as deprecated aliases:availableRoleshad a single internal consumer and retaining it would mean keeping the bulk roles fetch alive purely to populate a field nobody reads.Contributing
Summary by CodeRabbit
Bug Fixes
Localization
Improvements