Ролі та область дозволів

OpenFactory зберігає незалежні ролі на рівнях organization, unit і team. Назва ролі описує scope; це не universal permission, що автоматично застосовується до кожного API або функції продукту.

Модель scope


organization membership: owner | admin | member
└── unit membership: unit_admin | base_creator | base_approver | member
    └── team membership: team_lead | variant_creator | variant_deployer | variant_user

Organization membership , зовнішня межа. Користувач має бути member organization, перш ніж administrator додасть його до units або teams. Membership перевіряється незалежно на кожному рівні; не виводьте unit або team role з organization role, показаної в іншому контексті.

Organization roles

Поточний organization-management API застосовує ці permissions:

Operation	Owner	Admin	Member
View organization, members, groups, units, and teams	Yes	Yes	Yes
Edit organization name or description	Yes	Yes	No
Create, edit, or delete groups and manage group members	Yes	Yes	No
Invite or remove ordinary members	Yes	Yes	No
Change ordinary member/admin roles	Yes	Yes	No
Invite or promote an owner	Yes	No	No
Change or remove an existing owner	Yes	No	No
Create or delete units	Yes	Yes	No
Delete the organization	Yes	No	No
Leave the organization	Yes, unless the only owner	Yes	Yes

Organization може мати більше одного owner. API не дозволяє sole owner leave, доки не з’явиться інший owner або organization не deleted. Окремої дії «transfer ownership» у цьому API немає; owner змінює role іншого member на owner, потім може змінити або прибрати попереднього owner за задумом.

Unit roles

Organization owners і admins можуть керувати кожним unit. У unit поточний organization-management API надає unit_admin такі administrative operations:

edit unit;
add, remove і change unit-member roles;
create, edit і delete teams у цьому unit;
add і manage team members у цьому unit.

Лише organization owner або admin може delete unit.

base_creator, base_approver і unit member , stored role labels для base-image workflow policy. Organization CRUD routes самі по собі не доводять, що кожна create, approve або deployment action десь else enforce ці labels. Перевірте authorization behavior конкретного build або approval workflow перед покладанням як на control.

Team roles

Organization owners/admins і unit_admin батьківського unit можуть керувати team membership. team_lead може:

edit name або description team;
add і remove team members;
change team-member roles.

team_lead не може delete team через поточний organization API; ця operation зарезервована для organization owner/admin або parent unit_admin.

variant_creator, variant_deployer і variant_user виражають задумані variant-workflow responsibilities. Не читайте їх як доказ, що кожен variant endpoint enforce повну create/edit/deploy matrix. Перевірте exact workflow і denied paths у deployed release.

Groups , інше

Groups , organization-level sharing collections, не ще одна role hierarchy. Owners і admins створюють groups і керують group membership; усі organization members можуть list groups і їх members. Group membership не робить користувача organization admin, unit admin або team lead.

Безпечна зміна ролі

Підтвердіть target organization, unit або team.
Зафіксуйте current effective memberships користувача на всіх трьох scopes.
Застосуйте одну зміну ролі.
Перевірте allowed operation і denied operation сесією цього користувача.
Переконайтеся, що cached UI state і existing sessions відображають зміну.
Зберігайте audit record поза role label, якщо політика вимагає.

Зміна label без denied-path test , недостатній доказ, що least privilege enforced.

Типові edge cases

Admin не може promote anyone to owner або change role existing owner.
User не може бути added to unit або team, доки не belong to organization.
Unit і team members можуть remove themselves; organization membership лишається, якщо не removed окремо.
Removing organization membership слід перевірити на stale unit, team, group, share і session effects у вашому release.
UI badge colors , presentation, не security control. Завжди покладайтеся на server-side authorization і denied-path tests.