docs: expand user-invitations page to match actual feature behavior#1023
docs: expand user-invitations page to match actual feature behavior#1023leecalcote wants to merge 3 commits intomasterfrom
Conversation
- Fix domain wildcard format from *@Domain to @Domain (matches code) - Fix "Create Invitation" button label to "Create New Invitation" - Add required-permission callout (MANAGE_INVITATIONS) - Clarify email notification behavior: only exact-address invites send emails; domain wildcards and public invitations do not - Add isDefault ("Set as open signup invitation") to properties table - Expand managing-invitations section with column descriptions, quota display format (used / total), and filter (status/roles/teams) info - Add "What happens when a user accepts" section covering validation, org membership, and non-blocking role/team assignment - Fix unauthenticated redirect description: goes to registration page with orgId, not just the generic login page
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the documentation for the invitation system, adding information about required permissions, email notification behavior, and the new isDefault property. It also introduces a detailed section on the invitation acceptance process and improves the formatting and clarity of existing management actions and use cases. Feedback was provided to clarify that an invitation's expiration date only prevents new signups and does not automatically revoke access for users who have already joined.
| - Email: Use the partner's domain (e.g., `@partner.com`). | ||
| - Teams: Add them only to a shared project team (e.g., `Project-X-Shared`). | ||
| - Expiration date: Set to the project's end date to revoke access. | ||
| - Expiration date: Set to the project's end date to automatically revoke access. |
There was a problem hiding this comment.
The phrase "automatically revoke access" might be misleading in this context. An expiration date on an invitation record prevents new users from using that specific link to join the organization, but it does not automatically remove or revoke the membership of users who have already accepted the invitation and joined. For a scenario involving temporary partner access, it is important to clarify that existing members must be manually removed from the organization or teams when the project ends.
| - Expiration date: Set to the project's end date to automatically revoke access. | |
| - Expiration date: Set to the project's end date to prevent new signups after the project concludes. |
There was a problem hiding this comment.
Pull request overview
Expands and corrects the Layer5 Cloud User Invitations documentation so it matches current product behavior and UI (invitation patterns, permissions, notifications, filtering, and acceptance flow).
Changes:
- Corrected domain pattern examples/wording (use
@domain.comformat) and updated UI-referenced labels/redirect behavior. - Added documentation for required permission, email notification rules,
isDefault(open signup invitation), filtering, and table column behaviors. - Documented the invitation acceptance flow and clarified non-blocking role/team assignment behavior.
|
🚀 Preview deployment: https://layer5io.github.io/docs/pr-preview/pr-1023/
|
Expiring an invitation prevents new users from accepting the link but does not remove members who have already joined. Fix Scenario 4 which said "automatically revoke access", and add a warning that partners who already joined must be manually removed from the org/teams.
- Explain that orgs are closed by default: without a default invitation
configured (isDefault), no one can join an org through the
registration page automatically
- Clarify that users who join without an invitation get no role assigned;
roles come only from the invitation's roles list
- Document how to track acceptance: accepted count shown in Quota column
(always as "{accepted} / {quota}" or "{accepted} / Unlimited");
individual member list is in User Management
Summary
Audited the user-invitations documentation against the implementation in
meshery-cloud(ui/components/identity/invitations/index.tsx,server/handlers/invitations/handlers.go,server/handlers/invitations/service.go,ui/pages/invitations/[id]/accept.tsx) and found several inaccuracies and undocumented features.Fixes
*@layer5.io; code uses@layer5.io(prefix match on@). UI placeholder also shows@domain.com. Fixed throughout./registration?orgId=<id>. Fixed description to reflect this.Additions
MANAGE_INVITATIONSkey is checked on delete (and enforced by the UI); added an info alert at the top so readers know what access is needed.SendInvitationEmailToUsers. Added an alert clarifying this so admins know they need to share the link manually for non-individual invites.isDefaultproperty: the form exposes a "Set as open signup invitation" checkbox backed byisDefault.AcceptOpenOrgInvitationin the service usesorg.InviteIdto auto-enroll users who register through the org's registration flow. Added to the properties table with a clear description.used / totalquota display format and the copyable inline link.UniversalFilter. Added a short paragraph describing the available filters.Test plan
index.tsx@domain.comformat throughout