Udostępnianie conversations i variants

Sharing API przyznaje dostęp view lub edit do conversation/variant. Targets mogą być pojedynczym userem, group, organization, unit lub team.

Tylko owner conversation może tworzyć, zmieniać, listować lub usuwać shares.

Granica uprawnień

Te etykiety nie przyznają automatycznie każdej akcji downstream. Artifact download, VM launch, deployment, billing, secrets i organization administration mogą mieć osobne sprawdzenia owner i entitlement. Przetestuj każdą wymaganą akcję w session odbiorcy.

Jeśli ta sama conversation dociera do usera przez kilka shares, odpowiedź accessible-list wybiera wyższy poziom z view i edit.

Reguły target

• Bezpośrednie user shares są rozwiązywane względem organization membership.
• Groups, units i teams muszą należeć do właściwej organization.
• Organization shares obejmują bieżących członków organization.
• Zmiany membership mogą zmienić efektywny dostęp bez edycji samego share.

Nie używaj szerokiego organization share, gdy wystarczy user share lub team share.

Bezpieczny workflow sharing

1. Potwierdź conversation ID i owner.
2. Potwierdź recipient target i bieżące membership.
3. Zacznij od view, chyba że potrzebna jest edycja.
4. Utwórz jeden share i sprawdź zwrócony target i permission.
5. Zaloguj się jako odbiorca i przetestuj dozwolone i odrzucone operations.
6. Usuń lub ogranicz dostęp po zakończeniu zadania.
7. Odśwież recipient session i powtórz denied-path test.

Nie zakładaj, że wysłano e-mail ani in-app notification. Komunikuj się przez zatwierdzony kanał, bez tokenów ani prywatnych artifact URL.

Zachowanie przy współpracy

edit to authorization, nie conflict resolution. Zanim dwie osoby zmienią tę samą conversation, ustal, kto jest właścicielem następnej recipe revision, i porównaj znormalizowany output z pełnym chatem. Rebuild powinien być powiązany z konkretnym sprawdzonym recipe, a nie z edit, który dotarł jako ostatni.

Przegląd i offboarding

Okresowo inwentaryzuj:

• bezpośrednie shares;
• szerokie shares group, unit, team i organization;
• nieaktualne memberships, które nadal dają dostęp;
• resources, których pierwotny owner odszedł; oraz
• dostęp odbiorcy do starych builds, downloads i VMs.

Usunięcie share nie usuwa koniecznie kopii już pobranej przez odbiorcę. Postępuj z eksportowanymi artifacts zgodnie z polityką klasyfikacji danych i retention.