Organisationer

OpenFactorys organization API gemmer organisationsmedlemskaber plus valgfrie groups, units og teams. Den leverer også mål til deling af conversations/variants.

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

Denne hierarki er input til autorisation. Et rollemærke beviser ikke, at hvert build-, VM-, download- eller deployment-endpoint håndhæver den tilsigtede policy. Se Roller og tilladelsesomfang for de routes, der i øjeblikket styres af hver rolle.

Kerneobjekter

• Organization: grænse for medlemskab og administration på øverste niveau. En bruger kan tilhøre flere organizations.
• Group: navngiven samling af organization-medlemmer brugt som share-mål; ikke en administrativ hierarki.
• Unit: beholder i afdelingsstil med eget medlemskab og gemte workflow-roller.
• Team: underordnet unit med eget medlemskab og gemte workflow-roller.

Brugere skal være organization-medlemmer, før de tilføjes længere nede i strukturen.

Sikker opsætningsrækkefølge

1. Opret organization; opretteren bliver owner.
2. Tilføj en anden ansvarlig owner, før du stoler på organization til varige operationer.
3. Inviter brugere til deres præcise e-mailadresser og tildel den laveste nødvendige organization-rolle.
4. Tilføj units eller teams kun når deres omfang ændrer et faktisk workflow.
5. Test én tilladt og én afvist handling med hver repræsentativ rolle.
6. Gennemgå share- og medlemskabets adfærd efter fjernelse af rolle og session-opdatering.

Invitationer udløber og skal accepteres af en konto, hvis e-mail matcher invitationen. Send ikke invite tokens i tickets eller offentlige logs.

Kontekst og ejerskab

Valg af organization kan påvirke synlige samarbejdsdata, men enkelte resources har stadig regler for owner og share. Udled ikke adgang til privat build eller artifact alene fordi to brugere tilhører samme organization. Brug eksplicit deling hvor det understøttes, og test download-/VM-handlingen separat.

Isolationsbevis

Organization- og sharing-routes udfører membership checks og same-organization validation for deres afgrænsede operationer. “Tenant isolation” er en bredere systemegenskab og kræver cross-tenant denied-path-tests på tværs af conversations, builds, artifacts, VMs, API’er, caches, exports og logs. Brug ikke organization-hierarkiet alene som det bevis.

Beskyttelse ved administration

• Flere owners understøttes; den eneste owner kan ikke forlade.
• Kun en owner kan forfremme en anden owner eller slette organization.
• Sletning og fjernelse af medlemskab kan påvirke afhængig adgang. Kortlæg shares, units, teams, aktive sessioner og owned resources først.
• Bevar ekstern audit-post hvis jeres policy kræver det; en aktuel rolleliste er ikke et historisk audit trail.

Fortsæt med Sharing og Units and Teams.