- 
                Notifications
    You must be signed in to change notification settings 
- Fork 2.8k
Description
Is there an existing issue for this?
- I have searched the existing issues
Current behavior
Environment
Deployment: ☐ Cloud (SaaS) / ☑ Self-hosted
Plane version: 1.14.1 commercial
Browser(s): Chrome 140, Firefox 131
OS: Linux
Description
When inviting a user to a workspace with email A, the invitee can follow the invitation link and register with email B (different from the invited address). After doing so:
The user is not added to the workspace members list.
The original invitation for email A remains “Pending” in the admin view.
The newly created account (email B) has no access to the workspace and is not visible to the admin, leading to an inconsistent state.
Impact / Severity
Medium: Blocks onboarding for users who mistakenly (or intentionally) sign up with a different email, creating orphaned invites and hidden accounts not linked to the workspace.
Additional Notes / Possible Cause
The invite token appears to not bind strictly to the invited email, and there is no reconciliation step if the authenticated email differs from the invited one.
Workarounds
Ask invitees to sign up with exactly the invited email (A).
Revoke/delete the pending invite for A (if possible) and re-invite using the email the user actually used (B).
Suggested Fix
Bind the invitation token to the invited email and enforce it during sign-up;
or
Add a confirmation/remapping dialog: “This invite was sent to A, you’re signing in as B. Do you want to request access as B? The admin will be notified / The invite will be reassigned.”
Provide admin-side tooling to reassign an invite from A → B, or to accept B against the pending invite.
Reproducibility
100% in our environment.
Thanks for your help! Happy to test a patch or a canary build if needed.
Steps to reproduce
Steps to Reproduce
As a workspace admin, go to Workspace → Members (or Settings → Members) and click Add member.
Send an invitation to email A (e.g., [email protected]).
The invitee opens the invitation link from their inbox.
On the sign-up/join screen, the invitee chooses to sign up with email B that is different from the invited email A.
Complete sign-up.
Expected Behavior
Option A (strict): The invitation link enforces sign-up with the invited email (A), or blocks joining with a clear error message.
Option B (flexible but consistent): If the invitee signs up with email B, Plane should ask to confirm joining the workspace as B and associate the account to the invitation/workspace, or inform the admin to approve remapping A → B.
Actual Behavior
The invitation for email A remains “Pending” forever in the admin UI.
The user who registered with email B is not added to the workspace and is not listed in Members.
Admin has no clear way to associate the newly created account (B) to the existing invitation (A).
Environment
Production
Browser
Google Chrome
Variant
Self-hosted
Version
v1.14.1