Zum Hauptinhalt springen
Version: Weekly Build

Migration eines eigenständigen Teams in eine Organization

Diese Anleitung führt durch die Migration eines bestehenden, eigenständigen Teams in die neue Organization.

Da eine einheitliche Governance voraussetzt, dass alle Teammitglieder auch Mitglieder der Organization sind, kann es bei Migrationen zu Konflikten kommen, wenn das Team externe Nutzer enthält. Dieses Tutorial zeigt, wie ein solcher Konflikt über die API gelöst werden kann.

Szenario-Übersicht

Man ist Organization Admin und hat ein bestehendes Team (teamId: 42), das in die Organization verschoben werden soll. Allerdings sind zwei Nutzer dieses Teams ([email protected] und [email protected]) noch nicht Teil der Organization. Alice soll erhalten bleiben, während es kein Problem ist, wenn Bob im Zuge der Migration aus dem Team entfernt wird.

Schritt 1: Organization-ID abrufen

Bevor das Team migriert werden kann, muss die Ziel-organizationId bekannt sein. Dazu wird eine Liste aller Organizations abgerufen, denen man angehört.

  • Endpunkt: GET /organizations
  • Aktion: Die Ziel-Organization im Antwort-Array suchen und ihre id kopieren (z. B. 123e4567-e89b-12d3-a456-426614174000).
Schritt 2: Migration versuchen (und scheitern)

Wir versuchen, das Team zu migrieren. Da wir vorsichtig vorgehen möchten, lassen wir das force-Flag weg (Standardwert ist false).

  • Endpunkt: POST /teams/42/migrate

  • Payload:

    {
    "organizationId": "123e4567-e89b-12d3-a456-426614174000"
    }
  • Ergebnis: Die API lehnt die Anfrage ab, da Alice und Bob nicht Mitglieder der Organization sind. Es wird ein 400 Bad Request mit folgendem Fehlerdetail zurückgegeben:

    Cannot migrate team to organization because the following team members are not members of the new organization: [email protected], [email protected]. Either add the members to the organization before migrating, or use the force option to remove them from the team and proceed with the migration.

Schritt 3: Erforderliches Mitglied hinzufügen

Wir entscheiden, dass Alice im Team bleiben soll, und laden sie daher zunächst in die übergeordnete Organization ein.

  • Endpunkt: POST /organizations/123e4567-e89b-12d3-a456-426614174000/members
  • Payload:
    {
    "email": "[email protected]",
    "role": "member"
    }
  • Ergebnis: Alice ist nun offiziell Teil der Organization.
Schritt 4: Migration erzwingen

Wir möchten Bob nicht zur Organization hinzufügen und akzeptieren, dass er den Zugriff auf das Team nach der Migration verliert. Wir rufen den Migrations-Endpunkt erneut auf, dieses Mal mit explizit gesetztem force: true.

  • Endpunkt: POST /teams/42/migrate
  • Payload:
    {
    "organizationId": "123e4567-e89b-12d3-a456-426614174000",
    "force": true
    }
  • Ergebnis: Erfolg! HTTP 200 OK. Das Team wird in die Organization verschoben. Bob wird automatisch aus dem Team entfernt, während Alice Teammitglied bleibt.
Schritt 5: Migration überprüfen

Abschließend prüfen wir die Team-Liste unserer Organization, um sicherzustellen, dass das bestehende Team nun korrekt in unsere Governance-Struktur eingegliedert ist.

  • Endpunkt: GET /organizations/123e4567-e89b-12d3-a456-426614174000/teams
  • Ergebnis: Das Antwort-Array enthält nun das neu migrierte Team.