Organizacje

Organization API OpenFactory przechowuje członkostwa w organizacji oraz opcjonalne groups, units i teams. Dostarcza też cele do udostępniania conversations/variants.


organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

Ta hierarchia jest wejściem do autoryzacji. Etykieta roli nie dowodzi, że każdy endpoint build, VM, download lub deployment egzekwuje zamierzoną politykę. Zobacz Role i zakres uprawnień, aby zobaczyć trasy obecnie przypisane do każdej roli.

Obiekty podstawowe

Organization: granica członkostwa i administracji na najwyższym poziomie. Użytkownik może należeć do wielu organizations.
Group: nazwana kolekcja członków organization używana jako cel share; to nie jest hierarchia administracyjna.
Unit: kontener przypominający dział, z własnym członkostwem i zapisanymi rolami workflow.
Team: element podrzędny unit z własnym członkostwem i zapisanymi rolami workflow.

Użytkownicy muszą być członkami organization, zanim dodasz ich niżej w strukturze.

Bezpieczna kolejność konfiguracji

Utwórz organization; twórca staje się owner.
Dodaj drugiego odpowiedzialnego owner, zanim polegasz na organization w trwałych operacjach.
Zaproś użytkowników na dokładne adresy e-mail i przypisz najniższą wymaganą rolę organization.
Dodawaj units lub teams tylko wtedy, gdy ich zakres zmienia rzeczywisty workflow.
Przetestuj jedną dozwoloną i jedną odrzuconą akcję dla każdej reprezentatywnej roli.
Sprawdź zachowanie share i członkostwa po usunięciu roli i odświeżeniu sesji.

Zaproszenia wygasają i muszą zostać zaakceptowane przez konto, którego e-mail zgadza się z zaproszeniem. Nie przekazuj invite tokenów w ticketach ani publicznych logach.

Kontekst i własność

Wybór organization może wpływać na widoczne dane współpracy, lecz poszczególne resources nadal mają reguły owner i share. Nie wnioskuj o dostępie do prywatnego build lub artifact tylko dlatego, że dwóch użytkowników należy do tej samej organization. Użyj jawnego udostępnienia tam, gdzie jest obsługiwane, i osobno przetestuj akcję download/VM.

Dowód izolacji

Trasy organization i sharing wykonują membership checks oraz same-organization validation dla swoich operacji w zakresie. „Tenant isolation” to szersza właściwość systemu i wymaga cross-tenant denied-path tests obejmujących conversations, builds, artifacts, VMs, API, cache, exports i logs. Nie traktuj samej hierarchii organization jako tego dowodu.

Zabezpieczenia administracyjne

Obsługiwanych jest wielu owners; jedyny owner nie może odejść.
Tylko owner może awansować innego owner lub usunąć organization.
Usunięcie i wycofanie członkostwa może wpłynąć na zależny dostęp. Najpierw zinwentaryzuj shares, units, teams, aktywne sesje i owned resources.
Zachowaj zewnętrzny zapis audytu, jeśli wymaga tego Twoja polityka; bieżąca lista ról nie jest historycznym audit trail.

Kontynuuj z Sharing i Units and Teams.