Організації

Organization API OpenFactory зберігає членство в організаціях, а також опційні groups, units і teams. Воно також задає цілі для спільного доступу до conversations/variants.


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

Ця ієрархія , вхід для авторизації. Назва ролі не доводить, що кожен build, VM, download або deployment endpoint застосовує задуману політику. Див. Roles and Permission Scope для маршрутів, які зараз керуються кожною роллю.

Основні об’єкти

Organization: верхня межа членства та адміністрування. Користувач може належати кільком організаціям.
Group: іменована колекція членів організації як ціль share; це не адміністративна ієрархія.
Unit: контейнер на кшталт відділу з власним членством і збереженими workflow roles.
Team: дочірній елемент unit з власним членством і збереженими workflow roles.

Користувачі мають бути членами organization перед додаванням нижче.

Безпечна послідовність налаштування

Створіть organization; creator стає owner.
Додайте другого відповідального owner, перш ніж покладатися на organization для durable operations.
Запрошуйте користувачів на точні email addresses і призначайте найнижчу потрібну organization role.
Додавайте units або teams лише коли їхній scope змінює фактичний workflow.
Перевірте одну дозволену дію та одну заборонену для кожної представницької ролі.
Перегляньте share і membership після зняття ролі та оновлення сесії.

Запрошення мають термін дії; їх має прийняти обліковий запис з email, що збігається з invitation. Не передавайте invite tokens у tickets або public logs.

Контекст і власність

Вибір organization може впливати на видимі collaboration data, але окремі ресурси все одно мають owner і share rules. Не робіть висновку про доступ до private build або artifact лише тому, що два користувачі в одній organization. Використовуйте explicit share, де підтримується, і окремо перевірте download/VM action.

Докази ізоляції

Organization і sharing routes виконують membership checks і same-organization validation для scoped operations. «Tenant isolation» , ширша властивість системи; потрібні cross-tenant denied-path tests для conversations, builds, artifacts, VMs, APIs, caches, exports і logs. Не використовуйте лише organization hierarchy як такий доказ.

Заходи адміністрування

Підтримується кілька owners; sole owner не може leave.
Лише owner може promote another owner або delete organization.
Deletion і membership removal можуть вплинути на dependent access. Спочатку inventory shares, units, teams, active sessions і owned resources.
Зберігайте external audit record, якщо політика вимагає; поточний listing ролей , не historical audit trail.

Продовжуйте з Sharing і Units and Teams.