Skip to Content
OrganizationsUnits und Teams

Units und Teams

Units und Teams modellieren verschachtelte Mitgliedschaft in einer Organisation:

organization
└── unit
    └── team

Nutzen Sie sie, wenn eine stabile Abteilung oder Arbeitsgruppe ein eigenes Share-Target oder Admin-Scope braucht. Groups sind oft einfacher für ad-hoc Sharing.

Gespeicherte Rollen

ScopeRollen
Unitunit_admin, base_creator, base_approver, member
Teamteam_lead, variant_creator, variant_deployer, variant_user

unit_admin und team_lead haben definierte Membership-Management-Autorität in der Organisations-API. Creator-/Approver-/Deployer-Labels drücken beabsichtigte Workflow-Verantwortung aus, beweisen aber nicht Durchsetzung durch jeden Build- oder Deployment-Endpoint. Testen Sie den konkreten Workflow.

Mitgliedschaftsregeln

  • Eine Unit gehört zu einer Organisation.
  • Ein Team gehört zu einer Unit.
  • Ein User muss Organisationsmitglied sein, bevor er Unit oder Team beitritt.
  • Ein Team-Member sollte auch in der Parent-Unit sein; Admin-Routes erzwingen die Hierarchie beim Hinzufügen.
  • Organisations-Owner/Admins und scoped Admins haben unterschiedliche Management-Befugnisse, beschrieben in Rollen und Berechtigungsumfang.

Design-Hinweise

Legen Sie eine Unit nur an, wenn sie eine dauerhafte Grenze hat (Ownership, Approval-Verantwortung oder distinct Resource-Sharing-Scope). Legen Sie ein Team für eine kleinere Arbeitsgruppe innerhalb dieser Grenze an.

Beispiel:

Acme
├── Platform unit
│   ├── Image engineering team
│   └── Security review team
└── Product unit
    └── Device application team

Kodieren Sie kein Org-Chart ohne Authorization-Effekt. Extra-Verschachtelung erhöht stale Memberships und unerwartete vererbte Shares.

Sichere Änderungen

Bei Add, Rollenänderung oder Entfernung:

  1. Organisation, Unit, Team, User und aktuelle Rollen dokumentieren;
  2. eine Änderung vornehmen;
  3. erlaubte Operation testen;
  4. verweigerte Operation testen;
  5. refreshen oder reauthentifizieren für stale Session-Verhalten; und
  6. Shares prüfen, deren Target-Mitgliedschaft sich geändert hat.

User können mehreren Units und Teams angehören. Neue Mitgliedschaft transferiert oder entfernt keine alte.

Lösch-Grenze

Unit- oder Team-Löschung ist eine materielle Operation. Verlassen Sie sich nicht auf generische Aussagen wie „resources become unit-level“ oder „unassigned resources are archived“. Vor Löschung per Read-only-Inventar Memberships, Shares, abhängige Ressourcen, aktive Arbeit und externe Referenzen identifizieren. Exportieren Sie den nötigen Audit-Record und bestätigen Sie exaktes Cascade-Verhalten der ausgerollten Version.

Ist die Auswirkung unklar, entfernen Sie zuerst breites Sharing und Mitglieder, bewahren das Objekt und holen Sie Owner-Freigabe vor Löschung ein.

Conversations und Variants teilenReferenz