Repository navigation
Sharing: invite people to a list by email #55
Description
Endpoints
GET /api/lists/{id}/invites— pending email invites (live-verified{"invites":[]}).POST /api/lists/{id}/invites— invite by email address; the person may not have an account yet.DELETE /api/lists/{id}/invites/{token}— revoke a pending invite.
Acceptance criteria
- Service methods on
Services/InterlinedApiClient.Lists.cs, request shape verified live before typing the response strictly. - Pending invites listed in the list's share UI with the invited address, role and a Revoke action.
- Invite takes an email plus a permission level.
- Subscriber-gated with an upgrade prompt for free accounts — invite controls visible but locked, matching the web.
Activity
Adron commentedon Sep 16, 2026
Implemented in #168 — work continues in the PR from here.
The three list-invite endpoints are live-verified and wired into the Lists share UI through a new
Services/InterlinedApiClient.ListInvites.cspartial, so the contended.Lists.csis untouched. The UI is one reusableViews/InvitePanelcontrol (role picker, expiry, pending list with Copy link + Revoke) that #56 reuses for documents, and it costsListsView.xamla single line because the panel takes its target declaratively.Ownership and subscriber gating follow the product rules rather than the server error: only the true owner can manage sharing (not even an Admin collaborator), free accounts see the controls locked with an Upgrade prompt instead of hidden, and Revoke stays live for a lapsed subscriber. No invite was ever sent to a real address — probes used the reserved
.invalidTLD on a throwaway list that has since been deleted.Merge pull request #168 from CompositeCode/issue-55-list-invites