Organisasjoner

OpenFactorys organization API lagrer organisasjonsmedlemskap pluss valgfrie groups, units og teams. Den leverer også mål for deling av conversations/variants.

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

Dette hierarkiet er input til autorisasjon. En rolletikett beviser ikke at hvert build-, VM-, download- eller deployment-endpoint håndhever tiltenkt policy. Se Roller og tillatelsesomfang for rutene som for tiden styres av hver rolle.

Kjerneobjekter

• Organization: grense for medlemskap og administrasjon på øverste nivå. En bruker kan tilhøre flere organizations.
• Group: navngitt samling av organization-medlemmer brukt som share-mål; ikke et administrativt hierarki.
• Unit: beholder i avdelingsstil med eget medlemskap og lagrede workflow-roller.
• Team: underordnet unit med eget medlemskap og lagrede workflow-roller.

Brukere må være organization-medlemmer før de legges til lenger ned i strukturen.

Sikker oppsettrekkefølge

1. Opprett organization; oppretteren blir owner.
2. Legg til en andre ansvarlig owner før du stoler på organization for varige operasjoner.
3. Inviter brukere til nøyaktige e-postadresser og tildel laveste nødvendige organization-rolle.
4. Legg til units eller teams bare når omfanget deres endrer et faktisk workflow.
5. Test én tillatt og én avvist handling med hver representativ rolle.
6. Gjennomgå share- og medlemskapets atferd etter fjerning av rolle og øktoppdatering.

Invitasjoner utløper og må aksepteres av en konto hvis e-post samsvarer med invitasjonen. Ikke send invite tokens i saker eller offentlige logger.

Kontekst og eierskap

Valg av organization kan påvirke synlige samarbeidsdata, men enkelte resources har fortsatt regler for owner og share. Ikke slut at det finnes tilgang til privat build eller artifact bare fordi to brukere tilhører samme organization. Bruk eksplisitt deling der det støttes, og test download-/VM-handlingen separat.

Isolasjonsbevis

Organization- og sharing-ruter utfører membership checks og same-organization validation for sine avgrensede operasjoner. «Tenant isolation» er en bredere systemegenskap og krever cross-tenant denied-path-tester på tvers av conversations, builds, artifacts, VMs, API-er, caches, exports og logs. Ikke bruk organization-hierarkiet alene som det beviset.

Vern ved administrasjon

• Flere owners støttes; den eneste owner kan ikke forlate.
• Bare en owner kan forfremme en annen owner eller slette organization.
• Sletting og fjerning av medlemskap kan påvirke avhengig tilgang. Ta først oversikt over shares, units, teams, aktive økter og owned resources.
• Behold ekstern audit-post hvis policyen deres krever det; en gjeldende rolleliste er ikke et historisk audit trail.

Fortsett med Sharing og Units and Teams.