Dela conversations och variants

Sharing-API:t ger view- eller edit-åtkomst till en conversation/variant. Targets kan vara en enskild user, group, organization, unit eller team.

Endast conversation-ägaren kan skapa, ändra, lista eller ta bort shares.

Behörighetsgräns

Dessa etiketter ger inte automatiskt varje downstream-åtgärd. Artifact download, VM launch, deployment, billing, secrets och organization administration kan ha separata owner- och entitlement-kontroller. Testa varje nödvändig åtgärd med mottagarens session.

Om samma conversation når en user via flera shares väljer accessible-list-svaret det högre av view och edit.

Target-regler

• Direkta user shares matchas mot organization membership.
• Groups, units och teams måste tillhöra relevant organization.
• Organization shares når nuvarande organization members.
• Medlemsändringar kan ändra effektiv åtkomst utan att share redigeras.

Använd inte en bred organization share när user share eller team share räcker.

Säker sharing-workflow

1. Bekräfta conversation-ID och owner.
2. Bekräfta recipient target och nuvarande membership.
3. Börja med view om editing inte behövs.
4. Skapa en share och granska returnerat target och permission.
5. Logga in som mottagare och testa tillåtna och nekade operations.
6. Ta bort eller minska åtkomst när uppgiften är klar.
7. Uppdatera recipient session och upprepa denied-path-testet.

Anta inte att e-post eller in-app notification skickades. Kommunicera via er godkända kanal utan tokens eller privata artifact-URL:er.

Samarbetsbeteende

edit är authorization, inte conflict resolution. Innan två personer ändrar samma conversation, enas om vem som äger nästa recipe revision och jämför normaliserad output med hela chatten. En rebuild ska kopplas till ett specifikt granskat recipe, inte till den edit som kom in sist.

Granskning och offboarding

Inventera med jämna mellanrum:

• direkta shares;
• breda group-, unit-, team- och organization shares;
• inaktuella memberships som fortfarande ger åtkomst;
• resources vars ursprungliga owner lämnat; och
• mottagares åtkomst till gamla builds, downloads och VMs.

Att ta bort en share raderar inte nödvändigtvis en kopia som mottagaren redan laddat ner. Hantera exporterade artifacts enligt er data-classification- och retention policy.