You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #57 — Email invites for lists and documents (invite someone who has no account yet)
Invite by email form in the list access section: email + role (Read-only / Edit / Admin)
→ POST /api/lists/{id}/invites.
Pending invites list from GET /api/lists/{id}/invites showing email, role, status
(Pending → Accepted) and expiry.
Revoke via DELETE /api/lists/{id}/invites/{token}; the link must stop working immediately.
Revoking is free even when a subscription has lapsed — do not gate it behind the subscriber
check that guards sending.
Roles map to the API names already used in this module: Read-only = watcher, Edit = collaborator, Admin = manager.
Tests: send/list/revoke round-trips; revoke ungated by subscription.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in the PR above (branch issue/58-list-invites). Closing here — review and any follow-up happens on the PR.
Mirrors #59 as intended, including the two contract quirks it uncovered: the 201 returns no token (it has to be recovered from the landing URL, or you cannot revoke an invite you just sent), and there is no status field — the states are derived from accepted/expiresAt/revokedAt.
Two things need a decision from you:
A user-visible label mismatch now exists between the two sharing screens. Lists label the roles Read-only / Edit / Admin (this issue's wording); documents label the same API values Viewer / Editor / Admin (#59's, which matches the help centre's table). One of them should change.
A latent bug in :feature:documents was found and deliberately not fixed here:currentUserIsSubscriber() there treats CustomerStatus.UNKNOWN as not a subscriber, so an unrecognised customerStatus string — a future subscriber:lifetime, say — would lock a paying owner out of their own invite form without ever asking the server. This PR's lists version fails open instead. Filed separately.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/58-list-invites). Closing here — review and any follow-up happens on the PR.Mirrors #59 as intended, including the two contract quirks it uncovered: the 201 returns no
token(it has to be recovered from the landing URL, or you cannot revoke an invite you just sent), and there is nostatusfield — the states are derived fromaccepted/expiresAt/revokedAt.Two things need a decision from you:
A user-visible label mismatch now exists between the two sharing screens. Lists label the roles Read-only / Edit / Admin (this issue's wording); documents label the same API values Viewer / Editor / Admin (#59's, which matches the help centre's table). One of them should change.
A latent bug in
:feature:documentswas found and deliberately not fixed here:currentUserIsSubscriber()there treatsCustomerStatus.UNKNOWNas not a subscriber, so an unrecognisedcustomerStatusstring — a futuresubscriber:lifetime, say — would lock a paying owner out of their own invite form without ever asking the server. This PR's lists version fails open instead. Filed separately.merge: #58 list email invites (PR)