Deling af conversations og variants

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

Kun conversation-ejeren kan oprette, ændre, liste eller fjerne shares.

Tilladelsesgrænse

Disse labels giver ikke automatisk hver downstream-handling. Artifact download, VM launch, deployment, billing, secrets og organization administration kan have separate owner- og entitlement-tjek. Test hver påkrævet handling med modtagerens session.

Hvis samme conversation når en user via flere shares, vælger accessible-list-svaret det højere af view og edit.

Target-regler

• Direkte user shares afstemmes mod organization membership.
• Groups, units og teams skal høre til den relevante organization.
• Organization shares når nuværende organization members.
• Medlemsændringer kan ændre effektiv adgang uden at redigere selve share.

Brug ikke en bred organization share, når user share eller team share er nok.

Sikker sharing-workflow

1. Bekræft conversation-ID og owner.
2. Bekræft recipient target og nuværende membership.
3. Start med view, medmindre editing er påkrævet.
4. Opret én share og gennemgå returneret target og permission.
5. Log ind som modtager og test tilladte og afviste operations.
6. Fjern eller reducer adgang, når opgaven er slut.
7. Opdater recipient session og gentag denied-path-testet.

Antag ikke, at e-mail eller in-app notification er sendt. Kommuniker via jeres godkendte kanal uden tokens eller private artifact-URL’er.

Samarbejdsadfærd

edit er authorization, ikke conflict resolution. Før to personer ændrer samme conversation, aftal hvem der ejer næste recipe revision, og sammenlign normaliseret output med hele chatten. Et rebuild bør knyttes til et specifikt gennemgået recipe frem for den edit, der kom sidst.

Gennemgang og offboarding

Inventariser med jævne mellemrum:

• direkte shares;
• brede group-, unit-, team- og organization shares;
• forældede memberships, der stadig giver adgang;
• resources, hvis oprindelige owner er gået; og
• modtagers adgang til gamle builds, downloads og VMs.

At fjerne en share sletter ikke nødvendigvis en kopi, modtageren allerede har hentet. Håndter eksporterede artifacts via jeres data-classification- og retention policy.