Partage de conversations et variants

L’API de partage accorde l’accès view ou edit à une conversation/variant. Les cibles peuvent être un utilisateur, un groupe, une organisation, une unité ou une équipe.

Seul le propriétaire de la conversation peut créer, modifier, lister ou retirer ses partages.

Frontière de permission

Permission	Comportement conversation actuel
`view`	Lire la conversation/variant partagée et les métadonnées de build visibles associées.
`edit`	Inclut les modifications de conversation partagée et l’accès lié au rebuild implémenté par les routes conversation.

Ces libellés n’accordent pas automatiquement chaque action en aval. Téléchargement d’artefact, lancement VM, déploiement, facturation, secrets et administration organisation peuvent avoir des vérifications propriétaire et droits séparées. Testez chaque action requise avec la session du destinataire.

Si la même conversation atteint un utilisateur via plusieurs partages, la réponse accessible-list choisit le plus élevé entre view et edit.

Règles de cible

Les partages utilisateur direct sont résolus contre l’adhésion organisation.
Groupes, unités et équipes doivent appartenir à l’organisation pertinente.
Les partages organisation atteignent les membres organisation actuels.
Les changements d’adhésion peuvent changer l’accès effectif sans modifier le partage lui-même.

N’utilisez pas un partage organisation large lorsqu’un partage utilisateur ou équipe suffit.

Workflow de partage sûr

Confirmez l’ID de conversation et son propriétaire.
Confirmez la cible destinataire et l’adhésion courante.
Commencez par view sauf si l’édition est requise.
Créez un partage et inspectez la cible et la permission renvoyées.
Connectez-vous en tant que destinataire et testez opérations autorisées et refusées.
Retirez ou réduisez l’accès à la fin de la tâche.
Rafraîchissez la session destinataire et répétez le test de chemin refusé.

Ne supposez pas qu’une notification e-mail ou in-app a été envoyée. Communiquez via votre canal approuvé sans inclure jetons ou URL d’artefact privées.

Comportement de collaboration

edit est une autorisation, pas une résolution de conflit. Avant que deux personnes modifient la même conversation, convenez de qui possède la prochaine révision de recette et comparez la sortie normalisée avec le chat complet. Un rebuild doit être lié à une recette revue spécifique plutôt qu’à la dernière modification arrivée.

Relecture et offboarding

Inventoriez périodiquement :

partages directs ;
partages larges groupe, unité, équipe et organisation ;
adhésions obsolètes qui confèrent encore l’accès ;
ressources dont le propriétaire d’origine est parti ; et
accès destinataire à d’anciens builds, téléchargements et VM.

Retirer un partage ne supprime pas nécessairement une copie déjà téléchargée par un destinataire. Traitez les artefacts exportés via votre politique de classification et de rétention des données.