Ruoli e ambito permessi

OpenFactory memorizza ruoli indipendenti a livello organizzazione, unit e team. Un nome ruolo descrive uno scope; non è un permesso universale che si applica automaticamente a ogni API o feature prodotto.

Modello di 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

La membership organizzazione è il confine esterno. Un utente deve essere membro organizzazione prima che un amministratore possa aggiungerlo a unit o team. La membership è controllata indipendentemente a ogni livello; non inferire un ruolo unit o team da un ruolo organizzazione mostrato in un altro contesto.

Ruoli organizzazione

L’API gestione organizzazione corrente applica questi permessi:

Operazione	Owner	Admin	Member
Visualizzare organizzazione, membri, gruppi, unit e team	Sì	Sì	Sì
Modificare nome o descrizione organizzazione	Sì	Sì	No
Creare, modificare o eliminare gruppi e gestire membri gruppo	Sì	Sì	No
Invitare o rimuovere membri ordinari	Sì	Sì	No
Cambiare ruoli membro/admin ordinari	Sì	Sì	No
Invitare o promuovere un owner	Sì	No	No
Cambiare o rimuovere un owner esistente	Sì	No	No
Creare o eliminare unit	Sì	Sì	No
Eliminare l’organizzazione	Sì	No	No
Lasciare l’organizzazione	Sì, salvo unico owner	Sì	Sì

Un’organizzazione può avere più di un owner. L’API impedisce all’unico owner di uscire finché non esiste un altro owner o l’organizzazione non è eliminata. Non c’è un’azione separata «transfer ownership» in questa API; un owner cambia il ruolo di un altro membro in owner, poi può cambiare o rimuovere il prior owner come previsto.

Ruoli unit

Gli owner e admin organizzazione possono gestire ogni unit. Dentro un’unit, l’API gestione organizzazione corrente concede a unit_admin le seguenti operazioni amministrative:

modificare l’unit;
aggiungere, rimuovere e cambiare ruoli membri unit;
creare, modificare ed eliminare team in quell’unit;
aggiungere e gestire membri team in quell’unit.

Solo un owner o admin organizzazione può eliminare l’unit stessa.

base_creator, base_approver e member unit sono etichette ruolo memorizzate per policy workflow immagine base. Le route CRUD organizzazione da sole non provano che ogni azione create, approve o deploy altrove applichi quelle etichette. Verifica il comportamento autorizzazione del workflow build o approvazione specifico prima di usarlo come controllo.

Ruoli team

Gli owner/admin organizzazione e il unit_admin dell’unit genitore possono gestire membership team. Un team_lead può:

modificare nome o descrizione del team;
aggiungere e rimuovere membri team;
cambiare ruoli membri team.

Un team_lead non può eliminare il team tramite l’API organizzazione corrente; quell’operazione è riservata a owner/admin organizzazione o unit_admin genitore.

variant_creator, variant_deployer e variant_user esprimono le responsabilità workflow variant previste. Non vanno letti come prova che ogni endpoint variant applichi una matrice create/edit/deploy completa. Testa il workflow esatto e i percorsi negati nella release deployata.

I gruppi sono diversi

I gruppi sono collezioni share a livello organizzazione, non un’altra gerarchia ruoli. Owner e admin creano gruppi e gestiscono membership gruppo; tutti i membri organizzazione possono elencare gruppi e i loro membri. Membership gruppo non trasforma un utente in admin organizzazione, admin unit o team lead.

Cambiare un ruolo in sicurezza

Conferma organizzazione, unit o team target.
Registra le membership effettive correnti dell’utente a tutti e tre gli scope.
Applica un cambio ruolo.
Testa sia un’operazione consentita sia una negata con la sessione propria dell’utente.
Controlla che stato UI in cache e sessioni esistenti riflettano il cambio.
Conserva un record audit fuori dall’etichetta ruolo se la tua policy lo richiede.

Cambiare un’etichetta senza test denied-path non è evidenza sufficiente che least privilege sia applicato.

Casi limite comuni

Un admin non può promuovere nessuno a owner né cambiare il ruolo di un owner esistente.
Un utente non può essere aggiunto a unit o team finché non appartiene all’organizzazione.
Membri unit e team possono rimuovere se stessi; la membership organizzazione resta salvo rimozione separata.
Rimuovere membership organizzazione va controllata per effetti stale su unit, team, gruppo, share e sessione nella tua release.
I colori badge UI sono presentazione, non controllo sicurezza. Affidati sempre ad autorizzazione server-side e test denied-path.