Conversations und Variants teilen

Die Sharing-API gewährt view- oder edit-Zugriff auf eine Conversation/Variant. Targets können ein einzelner User, Group, Organization, Unit oder Team sein.

Nur der Conversation-Owner kann Shares anlegen, ändern, listen oder entfernen.

Berechtigungsgrenze

Diese Labels gewähren nicht automatisch jede Downstream-Aktion. Artefakt-Download, VM-Start, Deployment, Billing, Secrets und Organisations-Administration können separate Owner- und Entitlement-Checks haben. Testen Sie jede nötige Aktion mit der Session des Empfängers.

Erreicht dieselbe Conversation einen User über mehrere Shares, wählt die Accessible-List-Response das höhere von view und edit.

Target-Regeln

• Direkte User-Shares werden gegen Organisationsmitgliedschaft aufgelöst.
• Groups, Units und Teams müssen zur relevanten Organisation gehören.
• Organization-Shares erreichen aktuelle Organisationsmitglieder.
• Mitgliedschaftsänderungen können effektiven Zugriff ändern, ohne den Share selbst zu editieren.

Nutzen Sie keinen breiten Organization-Share, wenn User- oder Team-Share reicht.

Sicherer Sharing-Workflow

1. Conversation-ID und Owner bestätigen.
2. Empfänger-Target und aktuelle Mitgliedschaft bestätigen.
3. Mit view starten, sofern Edit nicht nötig ist.
4. Einen Share anlegen und zurückgegebenes Target und Permission inspizieren.
5. Als Empfänger anmelden und erlaubte sowie verweigerte Operationen testen.
6. Zugriff reduzieren oder entfernen, wenn die Aufgabe endet.
7. Empfänger-Session refreshen und Denied-Path-Test wiederholen.

Gehen Sie nicht davon aus, dass E-Mail oder In-App-Benachrichtigung gesendet wurde. Kommunizieren Sie über Ihren genehmigten Kanal ohne Tokens oder private Artefakt-URLs.

Kollaborations-Verhalten

edit ist Authorization, kein Conflict Resolution. Bevor zwei Personen dieselbe Conversation ändern, vereinbaren Sie, wer die nächste Rezept-Revision besitzt, und vergleichen Sie normalisierte Ausgabe mit dem vollen Chat. Ein Rebuild soll an ein konkret geprüftes Rezept gebunden sein, nicht an den zuletzt eingegangenen Edit.

Review und Offboarding

Periodisch inventarisieren:

• direkte Shares;
• breite Group-, Unit-, Team- und Organization-Shares;
• stale Memberships mit weiterhin Zugriff;
• Ressourcen, deren ursprünglicher Owner ging; und
• Empfänger-Zugriff auf alte Builds, Downloads und VMs.

Share-Entfernung löscht nicht zwingend eine bereits vom Empfänger heruntergeladene Kopie. Behandeln Sie exportierte Artefakte über Ihre Datenklassifikations- und Retention-Policy.