fix(invite): honor --role when re-inviting an existing member#234
Merged
Conversation
Re-inviting an existing member reused their current role and skipped role resolution, so an explicit --role (or interactive role change) was silently ignored — re-inviting to promote/demote was a no-op. It was also fragile across kick -> re-invite: if listMemberDetails read a not-yet-propagated membership, the stale role was kept. Take the silent re-issue path only when no role is requested (existingMember && !opts.role); otherwise resolve the role normally and let the service's addUserToOrgWithRole upgrade the membership. Keep the member's existing project scope by default on re-issue. Surfaced by the e2e protected-branch test: under the harness the CLI runs non-interactively (piped stdin), so the interactive role prompt never ran and re-invite-as-admin silently fell back to member.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
capy invite <existing-member>reused the member's current role and skipped role resolution entirely, so an explicit--role(or an interactive role change) was silently ignored — re-inviting to promote/demote was a no-op. It was also fragile acrosskick→ re-invite: iflistMemberDetailsread a not-yet-propagated WorkOS membership, the stale role was kept.Fix
Take the silent re-issue path only when no role is requested:
The service already supports this —
addUserToOrgWithRolecatches the 409 andupdateMembershipRoles when the requested role differs ("re-inviting to promote is a silent no-op"). So sending the requested role is all that's needed, and it's race-proof (the requested role wins even if a stale membership is read).How it surfaced
The e2e protected-branch test failed because under the harness the CLI runs non-interactively (piped stdin →
isInteractive()is false), so the role prompt never ran and re-invite-as-admin fell back tomember. The harness is being fixed separately (pass--roleexplicitly) in the monorepo; this PR makes the CLI honor that role on re-invite.Tests
Full monorepo e2e suite green (44/44) against the dev service with this + the harness fix. No CLI unit tests touch this path's role branching; behavior verified end-to-end.