Deling av conversations og variants

Sharing-API-et gir view- eller edit-tilgang til en conversation/variant. Targets kan være en enkelt user, group, organization, unit eller team.

Bare conversation-eieren kan opprette, endre, liste eller fjerne shares.

Tillatelsesgrense

Disse etikettene gir ikke automatisk hver downstream-handling. Artifact download, VM launch, deployment, billing, secrets og organization administration kan ha separate owner- og entitlement-sjekker. Test hver nødvendig handling med mottakerens session.

Hvis samme conversation når en user via flere shares, velger accessible-list-responsen det høyere av view og edit.

Target-regler

• Direkte user shares løses mot organization membership.
• Groups, units og teams må tilhøre relevant organization.
• Organization shares når nåværende organization members.
• Medlemsendringer kan endre effektiv tilgang uten å redigere selve share.

Ikke bruk en bred organization share når user share eller team share er nok.

Sikker sharing-workflow

1. Bekreft conversation-ID og owner.
2. Bekreft recipient target og nåværende membership.
3. Start med view med mindre editing er påkrevd.
4. Opprett én share og inspiser returnert target og permission.
5. Logg inn som mottaker og test tillatte og avviste operations.
6. Fjern eller reduser tilgang når oppgaven er ferdig.
7. Oppdater recipient session og gjenta denied-path-testen.

Ikke anta at e-post eller in-app notification ble sendt. Kommuniser via godkjent kanal uten tokens eller private artifact-URL-er.

Samarbeidsatferd

edit er authorization, ikke conflict resolution. Før to personer endrer samme conversation, avtal hvem som eier neste recipe revision, og sammenlign normalisert output med hele chatten. Et rebuild bør knyttes til et spesifikt gjennomgått recipe, ikke til den edit-en som kom sist.

Gjennomgang og offboarding

Inventariser med jevne mellomrom:

• direkte shares;
• brede group-, unit-, team- og organization shares;
• utdaterte memberships som fortsatt gir tilgang;
• resources der opprinnelig owner har gått; og
• mottakers tilgang til gamle builds, downloads og VMs.

Å fjerne en share sletter ikke nødvendigvis en kopi mottakeren allerede har lastet ned. Håndter eksporterte artifacts via data-classification- og retention policy.