Concetto di autorizzazione

Gruppi / ruoli - Come funzionano?

In hitobito possono essere mappate organizzazioni gerarchiche complesse. Tutto si basa sul fatto che consentiamo diversi tipi di gruppo, che definiscono anche quali ruoli sono disponibili.

Ogni organizzazione può essere composta da più livelli, ad es. associazione mantello, associazione cantonale (, livelli intermedi facoltativi come le regioni) e gruppi locali.
Ogni livello può avere una propria struttura interna, c’è un consiglio, gruppi di lavoro, elenchi di membri, elenchi di contatti.
Ogni persona ha uno o più ruoli. Questi ruoli definiscono chi puoi vedere e da chi puoi essere visto.

Ecco alcuni esempi di come può apparire.

Karin è il capo direttamente nell’organizzazione mantello

tecnicamente: layer_and_below_full direttamente nell’associazione mantello, incl. contact_data

Karin vede:

Karin ha pieno accesso al suo livello e a tutti i livelli inferiori. Questo le permette di vedere e cambiare tutti nell’organizzazione mantello, nelle regioni e al livello più alto dei gruppi locali. Tutte le persone che sono collegate a un gruppo locale, cioè in un sottogruppo del gruppo locale, non sono visibili per lei e non possono essere modificate. Poiché il ruolo di Karin è elencato come rilevante per il contatto (il cosiddetto flag ContactData, vedi sotto), può vedere tutte le altre persone con rilevanza per il contatto, indipendentemente dalla loro posizione all’interno della struttura.

Karin è vista da:

Karin è visibile a tutte le altre persone con diritti all’interno del livello dell’organizzazione mantello. A causa della rilevanza del contatto del ruolo di Karin, è visibile anche a tutti gli altri ruoli rilevanti per il contatto.

Luca è membro di un comitato nell’organizzazione mantello

tecnicamente: group_read nel gremio senza``contact_data``

Luca vede:

Luca vede tutti i membri e la direzione all’interno del gremio. Altrimenti non vede nessuno al di fuori del gremio.

Luca è visto da:

Luca è visibile e modificabile per le persone con pieni diritti (layer_full o layer_and_below_full) per il livello di organizzazione mantello. Inoltre, la direzione all’interno del suo gremio può visualizzare e modificare i suoi dati (group_full). I suoi colleghi con lo stesso ruolo nel comitato possono vedere i suoi dati ma non possono cambiarli (group_read)

Maria assume un ruolo nella regione

tecnicamente: group_read incl. contact_data

Maria vede

Maria può vedere tutti i membri del suo gruppo, ovvero tutti i collaboratori a livello regionale.

Poiché il ruolo di Maria è elencato come rilevante per il contatto (il cosiddetto flag ContactData, vedi sotto), può vedere tutte le altre persone con rilevanza per il contatto, indipendentemente dalla loro posizione all’interno della struttura.

Maria è vista da

Maria è visibile a tutte le altre persone con diritti all’interno del livello di organizzazione mantello. A causa della rilevanza di contatto del ruolo di Maria, è visibile anche a tutti gli altri ruoli rilevanti per il contatto.

Petra dirige un gremio nella regione

tecnicamente: layer_read incl. contact_data

Petra vede:

Petra vede tutte le persone nella regione, comprese le persone in tutti i sottogruppi. Tuttavia, non vede persone in gruppi locali attaccati alla regione.

Poiché il ruolo di Petra è gestito come rilevante per il contatto (il cosiddetto flag ContactData, vedi sotto), può vedere tutte le altre persone con rilevanza per il contatto, indipendentemente dalla loro posizione all’interno della struttura.

Petra è vista da

Petra è visibile alle persone a livello di cantone o organizzazione mantello che hanno un ruolo con accesso ai livelli inferiori (layer_and_below). Inoltre, tutte le persone nella regione che hanno diritti all’interno del gruppo o livello possono vedere i suoi dati.

A causa della rilevanza del contatto del ruolo di Petra, è visibile anche a tutti gli altri ruoli rilevanti per il contatto.

Anna dirige un gruppo locale

tecnicamente: layer_full incl. contact_data

Anna vede

Anna vede tutte le persone all’interno del gruppo locale.

Poiché il ruolo di Anna è elencato come rilevante per il contatto (il cosiddetto flag ContactData, vedi sotto), può vedere tutte le altre persone con rilevanza per il contatto, indipendentemente dalla loro posizione all’interno della struttura.

Anna è vista da

Anna è visibile alle persone al di sopra del gruppo locale se hanno il diritto di vedere le persone al di sotto del loro livello. Inoltre, i loro colleghi all’interno del gruppo locale possono vedere i loro dati se hanno diritto per il gruppo o il livello. A causa della rilevanza di contatto del ruolo di Anna, è visibile anche a tutti gli altri ruoli rilevanti per il contatto.

Franz guida un’unità all’interno di un gruppo locale

tecnicamente: layer_read (senza contact_data)

Franz vede

Franz vede tutte le persone all’interno del gruppo locale, ma non può cambiarle.

Franz è visto da

Franz è visibile alle persone del gruppo locale se hanno il diritto di vedere le persone all’interno dell’intero livello. Le persone al di sopra del gruppo locale non possono vedere Franz.

Jonas è un membro di un gruppo nel gruppo locale

tecnicamente: none

Jonas vede

Jonas non vede altre persone.

Jonas è visto da

Jonas è visibile alle persone del gruppo locale se hanno il diritto di vedere le persone all’interno dell’intero livello. Le persone al di sopra del gruppo locale non possono vedere Jonas.

Accumulo di ruoli all’interno della struttura

Gli accessi da più ruoli si accumulano. Un membro di un gruppo locale che è allo stesso tempo attivo nella regione è ancora visibile alla dirigenza regionale.

Date in eventi (campi, corsi)

I partecipanti a un evento possono visualizzare l’elenco dei partecipanti e vedere i loro contatti reciproci lì. I dati sono visibili solo nel contesto di «Evento» quando si naviga verso la persona tramite l’elenco dei partecipanti. Nel contesto di un «gruppo», durante la navigazione verso la persona tramite la gerarchia del gruppo, i diritti di accesso si applicano in base ai diritti basati sulla struttura di cui sopra.

Caso speciale `Contact_Data`

Se il ruolo di una persona è contrassegnato come rilevante per il contatto, questa persona ha accesso a tutte le altre persone con ruoli rilevanti per il contatto. Allo stesso tempo, è visibile anche a tutte le altre persone con ruoli rilevanti per il contatto. Ciò include ruoli che vengono spesso scambiati con persone di altri gruppi locali.

Caso speciale `finance`

Consente di creare e visualizzare fatture al livello appropriato.

Caso speciale `impersonation`

Può rilevare temporaneamente altri account, ad es. per compiti di supporto o per tests. Questa è una caratteristica molto potente e dovrebbe essere assegnata solo a ruoli chiaramente definiti.

Security: richieste di accesso e concessione manuale

Supponiamo che Anna desideri l’accesso non autorizzato alle informazioni personali di John. Per fare ciò, Anna può semplicemente aggiungere John a un gruppo, evento o abbonamento a cui ha diritti di accesso. Questo problema di protezione dei dati può essere prevenuto in hitobito con i «concessione manuale».

Quando si aggiunge John a gruppi, eventi e abbonamenti, hitobito controlla il ruolo principale di John (il ruolo contrassegnato da un asterisco). Se John non ha più un ruolo attivo, hitobito controllerà invece l’ultimo ruolo che era ancora attivo. Viene controllato se i rilasci manuali sono attivati nel livello di questo ruolo. Esempio: John ha il suo ruolo principale nel gruppo di lavoro «Saturno» dell’associazione «Osservatori di stelle Lucerna». Le approvazioni manuali possono essere attivate a livello (Associazione osservatori di stelle Lucerna) nella scheda Richieste.

Se nel livello sono attivati rilasci manuali, John non verrà aggiunto direttamente al nuovo gruppo, evento o abbonamento straniero, ma verrà attivata una richiesta di accesso. Anna vede quindi il seguente messaggio:

Tutte le persone selezionate nella scheda Richieste, più John se ha un login, riceveranno un’e-mail che le informa che Anna desidera aggiungere John a una nuova posizione. Da questa email o dalla scheda Richieste del gruppo, la richiesta di accesso può essere accettata o negata.

In questo modo, Anna non ottiene mai l’accesso non autorizzato ai dati personali di John. Tuttavia, il tutto funziona solo se i rilasci manuali sono attivati al livello. Nessuna richiesta di accesso viene attivata se Anna ha già accesso a John (ad esempio se entrambi hanno un ruolo con contact_data).