Organizzazioni

L’API organizzazioni OpenFactory memorizza membership organizzazione più gruppi, unit e team opzionali. Fornisce anche target per condividere conversazioni/varianti.

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

Questa gerarchia è un input di autorizzazione. Un’etichetta ruolo non prova che ogni build, VM, download o endpoint deploy applichi la policy prevista. Vedi Ruoli e ambito permessi per le route attualmente governate da ogni ruolo.

Oggetti principali

• Organization: confine membership e amministrazione top-level. Un utente può appartenere a più organizzazioni.
• Group: collezione nominata di membri organizzazione usata come target share; non è una gerarchia amministrativa.
• Unit: contenitore tipo reparto con membership propria e ruoli workflow memorizzati.
• Team: figlio di un’unit con membership propria e ruoli workflow memorizzati.

Gli utenti devono essere membri organizzazione prima di essere aggiunti sotto di essa.

Sequenza setup sicura

1. Crea l’organizzazione; il creatore diventa owner.
2. Aggiungi un secondo owner responsabile prima di affidare operazioni durature all’organizzazione.
3. Invita utenti ai loro indirizzi email esatti e assegna il ruolo organizzazione minimo richiesto.
4. Aggiungi unit o team solo quando il loro scope cambia un workflow reale.
5. Testa un’azione consentita e una negata con ogni ruolo rappresentativo.
6. Rivedi comportamento share e membership dopo rimozione ruolo e refresh sessione.

Gli inviti scadono e devono essere accettati da un account il cui email corrisponde all’invito. Non trasmettere token invito in ticket o log pubblici.

Contesto e ownership

La selezione organizzazione può influire sui dati collaborazione visibili, ma le risorse singole portano ancora regole owner e share. Non inferire accesso a build o artefatto privati solo perché due utenti appartengono alla stessa organizzazione. Usa share esplicita dove supportata e testa download/azione VM separatamente.

Evidenza isolamento

Le route organizzazione e sharing eseguono controlli membership e validazione stessa-organizzazione per le operazioni nel loro scope. «Isolamento tenant» è una proprietà di sistema più ampia e richiede test denied-path cross-tenant su conversazioni, build, artefatti, VM, API, cache, export e log. Non usare la sola gerarchia organizzazione come quella evidenza.

Salvaguardie amministrazione

• Sono supportati più owner; l’unico owner non può uscire.
• Solo un owner può promuovere un altro owner o eliminare l’organizzazione.
• Eliminazione e rimozione membership possono influire su accesso dipendente. Inventaria share, unit, team, sessioni attive e risorse possedute prima.
• Conserva un record audit esterno se la tua policy lo richiede; un elenco ruoli corrente non è una traccia audit storica.

Continua con Condivisione e Unit e team.