Closed
Labels
P1Table stakesTable stakesarea:documentsArea: documentsArea: documentsarea:sharingArea: sharingArea: sharingparityWeb/API feature-parity workWeb/API feature-parity work
Description
Same as the list invites, against /api/documents/{id}/invites (GET/POST) and DELETE /api/documents/{id}/invites/{token}.
Acceptance criteria
- Service methods on
Services/InterlinedApiClient.Documents.cs. - Pending invites listed with address, role and Revoke in the document's share UI.
- Subscriber-gated with the same locked-but-visible treatment.
- Shares one invite component with the list flow rather than duplicating it.
Metadata
Metadata
Assignees
Labels
P1Table stakesTable stakesarea:documentsArea: documentsArea: documentsarea:sharingArea: sharingArea: sharingparityWeb/API feature-parity workWeb/API feature-parity work
Activity
Adron commentedon Sep 16, 2026
Implemented in #169 (stacked on #168) — work continues in the PR from here.
The document invite endpoints are live-verified and wired into the document Share card via a new
Services/InterlinedApiClient.DocumentInvites.cspartial, leaving the contended.Documents.csuntouched. Per the acceptance criteria it shares the exact sameViews/InvitePanelcontrol as the list flow rather than duplicating it — the invite payloads turned out byte-identical, so this PR only adds a service partial, a target adapter, one factory line and one view line, and the panel leads the Share card the way the web does.The one real difference from lists is the ownership envelope (
documentvsdata), handled in the new partial. No invite was sent to a real address — probes used the reserved.invalidTLD on a throwaway document that has since been deleted.Merge pull request #169 from CompositeCode/issue-56-document-invites