Skip to Content
OrganizationsConversations- ja variant-jakaminen

Conversations- ja variant-jakaminen

Sharing-API myöntää view- tai edit-oikeuden conversation/variantiin. Targets voivat olla yksittäinen user, group, organization, unit tai team.

Vain conversationin omistaja voi luoda, muuttaa, listata tai poistaa shares.

Oikeusraja

PermissionNykyinen conversation-käyttäytyminen
viewJaetun conversation/variantin ja siihen liittyvien näkyvien build-metatietojen lukeminen.
editSisältää jaetun conversationin muokkaukset ja conversation routes -toteutetun rebuild-liittyvän pääsyn.

Nämä labelit eivät automaattisesti anna jokaista downstream-toimintoa. Artifact download, VM launch, deployment, billing, secrets ja organization administration voivat vaatia erilliset owner- ja entitlement-tarkistukset. Testaa jokainen tarvittava toiminto vastaanottajan sessionilla.

Jos sama conversation tavoittaa userin useiden shares kautta, accessible-list-vastaus valitsee korkeamman view- ja edit-oikeuksista.

Target-säännöt

  • Suorat user shares ratkaistaan organization membershipiin nähden.
  • Groups, units ja teams kuuluvat oikeaan organizationiin.
  • Organization shares ulottuvat nykyisiin organization members -jäseniin.
  • Membership-muutokset voivat muuttaa tehokasta pääsyä muuttamatta itse sharea.

Älä käytä laajaa organization sharea, jos user share tai team share riittää.

Turvallinen sharing-workflow

  1. Vahvista conversation-ID ja owner.
  2. Vahvista recipient target ja nykyinen membership.
  3. Aloita view-oikeudella, ellei editing ole tarpeen.
  4. Luo yksi share ja tarkista palautettu target ja permission.
  5. Kirjaudu vastaanottajana ja testaa sallitut ja evätyt operations.
  6. Poista tai rajaa pääsy, kun tehtävä on valmis.
  7. Päivitä recipient session ja toista denied-path-testi.

Älä oleta, että sähköposti tai in-app notification lähetettiin. Viesti hyväksytyllä kanavalla ilman tokeneita tai yksityisiä artifact-URL-osoitteita.

Yhteistyökäyttäytyminen

edit on authorization, ei conflict resolution. Ennen kuin kaksi henkilöä muuttaa samaa conversationia, sovi kuka omistaa seuraavan recipe revisionin ja vertaa normalisoitua outputia koko chatiin. Rebuild pitäisi sitoa tiettyyn tarkistettuun recipeen, ei viimeiseksi saapuneeseen editiin.

Tarkistus ja offboarding

Inventoi säännöllisesti:

  • suorat shares;
  • laajat group-, unit-, team- ja organization shares;
  • vanhentuneet memberships, jotka antavat edelleen pääsyn;
  • resources, joiden alkuperäinen owner on poistunut; ja
  • vastaanottajan pääsy vanhoihin buildeihin, downloadeihin ja VM:iin.

Sharen poistaminen ei välttämättä poista vastaanottajan jo lataamaa kopiota. Käsittele viedyt artifacts data-classification- ja retention policy -mukaisesti.