Partajarea conversations și variants
Sharing API acordă acces view sau edit la o conversation/variant. Targets pot fi un user individual, group, organization, unit sau team.
Doar owner-ul conversation poate crea, modifica, lista sau elimina shares.
Limita permisiunilor
| Permission | Comportamentul curent al conversation |
|---|---|
view | Citirea conversation/variant partajate și a metadatelor de build vizibile asociate. |
edit | Include editarea conversation partajate și accesul legat de rebuild implementat de conversation routes. |
Aceste etichete nu acordă automat fiecare acțiune ulterioară. Artifact download, VM launch, deployment, billing, secrets și administrarea organization pot avea verificări separate de owner și entitlement. Testați fiecare acțiune necesară în session-ul recipientului.
Dacă aceeași conversation ajunge la un user prin mai multe shares, răspunsul accessible-list alege nivelul mai ridicat dintre view și edit.
Reguli pentru targets
- User shares directe se rezolvă în funcție de organization membership.
- Groups, units și teams trebuie să aparțină organization relevante.
- Organization shares ajung la membrii actuali ai organization.
- Schimbările de membership pot modifica accesul efectiv fără a edita share-ul în sine.
Nu folosiți un organization share larg când un user share sau team share este suficient.
Workflow sigur de partajare
- Confirmați conversation ID și owner.
- Confirmați recipient target și membership-ul curent.
- Începeți cu
viewdacă nu este necesară editarea. - Creați un share și verificați target și permission returnate.
- Autentificați-vă ca recipient și testați operațiile permise și respinse.
- Eliminați sau reduceți accesul când sarcina se încheie.
- Reîmprospătați recipient session și repetați denied-path test.
Nu presupuneți că s-a trimis e-mail sau in-app notification. Comunicați prin canalul aprobat, fără tokeni sau artifact URL private.
Comportament la colaborare
edit este authorization, nu conflict resolution. Înainte ca două persoane să modifice aceeași conversation, stabiliți cine deține următoarea recipe revision și comparați output-ul normalizat cu chat-ul complet. Un rebuild ar trebui legat de un recipe revizuit concret, nu de edit-ul care a sosit ultimul.
Revizuire și offboarding
Inventariați periodic:
- shares directe;
- shares largi group, unit, team și organization;
- membership învechit care încă acordă acces;
- resources al căror owner inițial a plecat; și
- accesul recipientului la builds, downloads și VMs vechi.
Eliminarea unui share nu șterge neapărat o copie deja descărcată de recipient. Gestionați artifacts exportate conform politicii de clasificare a datelor și retention.