Concept d’autorisation
Groupes / rôles - Comment ça fonctionne ?
hitobito permet de représenter des organisations hiérarchiques complexes. Le principe est de pouvoir créer différents types de groupes, lesquels définissent également les rôles possibles.
Chaque organisation peut se composer de plusieurs niveaux, par exemple l’association faîtière, l’association cantonale (, des niveaux intermédiaires optionnels comme les régions) et les groupes locaux.
Chaque niveau peut à nouveau avoir sa structure propre en interne, il peut y avoir un comité, des groupes de travail, des listes de membres, des listes de contacts.
Chaque personne a un ou plusieurs rôles. Ces rôles définissent qui on peut voir et par qui on est vu.
Voici quelques exemples de ce à quoi cela pourrait ressembler.
Karine est secrétaire générale directement au sein de l’association faîtière
technique : layer_and_below_full directement dans l’association faîtière, y compris contact_data
Karine voit :
Karin a un accès complet sur son niveau et sur tous les niveaux inférieurs. Elle peut ainsi voir et modifier toutes les personnes de l’association faîtière, des régions et du plus haut niveau des groupes locaux. Elle ne peut ni voir ni modifier toutes les personnes qui se trouvent dans un groupe local, c’est-à-dire dans un sous-groupe subordonné au groupe local. Comme le rôle de Karine est classé comme important pour les contacts (« ContactData-Flag », voir ci-dessous), elle peut voir toutes les autres personnes importantes pour les contacts, indépendamment de leur position dans la structure.
Voient Karine :
Karine est visible pour toutes les autres personnes ayant des droits au niveau de l’association faîtière. En raison de son importance pour les contacts, le rôle de Karin est également visible pour tous les autres rôles ayant une importance pour les contacts.
Luca est membre d’un organe de l’association faîtière
techniquement : group_read dans un organe sans contact_data
Luca voit :
Luca voit tou·te·s les membres et la maîtrise au sein de l’organe. Il ne voit personne d’autre en dehors de son organe.
Voient Luca :
Luca est visible et modifiable par les personnes ayant les pleins droits (layer_full ou layer_and_below_full) au niveau de l’association faîtière. De plus, la maîtrise de son organe peut voir et modifier ses données (group_full). Ses collègues ayant le même rôle dans le comité voient ses données, mais ne peuvent pas les modifier (group_read).
Maria a un rôle dans une région
technique : group_read y compris contact_data
Maria voit :
Maria peut voir tous les membres de son groupe, c’est-à-dire tou·te·s les collaborateur·trice·s au niveau régional.
Comme le rôle de Maria est classé comme important pour les contacts (« ContactData-Flag », voir ci-dessous), elle peut voir toutes les autres personnes importantes pour les contacts, indépendamment de leur position dans la structure.
Voient Maria :
Maria est visible pour toutes les autres personnes ayant des droits au niveau de l’association faîtière. En raison de son importance pour les contacts, le rôle de Maria est également visible par tous les autres rôles ayant une importance pour les contacts.
Petra gère un organe dans une région
technique : layer_read y compris contact_data
Petra voit :
Petra voit toutes les personnes de sa région, y compris celles des éventuels sous-groupes. Cependant, elle ne voit pas les personnes des groupes locaux qui sont rattachés à la région.
Comme le rôle de Petra est classé comme important pour les contacts (« ContactData-Flag », voir ci-dessous), elle peut voir toutes les autres personnes importantes pour les contacts, indépendamment de leur position dans la structure.
Voient Petra :
Petra est visible par les personnes au niveau cantonal ou de l’association faîtière qui ont un rôle avec accès aux niveaux inférieurs (layer_and_below). De plus, toutes les personnes de la région qui ont des droits au sein du groupe ou du niveau voient ses données.
En raison de son importance pour les contacts, le rôle de Maria est également visible par tous les autres rôles ayant une importance pour les contacts.
Anna gère un groupe local
technique : layer_full y compris contact_data
Anna voit :
Anna voit toutes les personnes au sein du groupe local.
Comme le rôle d’Anna est classé comme important pour les contacts (« ContactData-Flag », voir ci-dessous), elle peut voir toutes les autres personnes importantes pour les contacts, indépendamment de leur position dans la structure.
Voient Anna :
Anna est visible par les personnes situées au-dessus du groupe local si elles ont l’autorisation de voir les personnes situées en dessous de leur niveau. De plus, ses collègues au sein du groupe local peuvent voir ses données s’iels ont le droit de voir les membres du groupe ou du niveau. En raison de son importance pour les contacts, le rôle d’Anna est également visible par tous les autres rôles ayant une importance pour les contacts.
François gère une unité au sein d’un groupe local
technique : layer_read (sans contact_data)
François voit :
François voit toutes les personnes au sein du groupe local, mais ne peut pas les modifier.
Voient François :
François est visible par les personnes du groupe local si celles-ci ont le droit de voir les personnes de tout le niveau. Les personnes appartenant à un niveau supérieur ne peuvent pas voir François.
Jonas est membre d’un groupe au sein d’un groupe local
techniquement : none
Jonas voit :
Jonas ne voit personne d’autre.
Voient Jonas :
Jonas est visible par les personnes du groupe local si celles-ci ont le droit de voir les personnes de l’ensemble du niveau. Les personnes appartenant à un niveau supérieur ne peuvent pas voir Jonas.
Cumul de rôles au sein de la structure
Les accès obtenus par plusieurs rôles se cumulent. Ainsi, un·e membre d’un groupe local qui est aussi actif·ive dans une région est tout de même visible par la maîtrise de la région.
Données dans les événements (camps, cours)
Les participant·e·s à un événement peuvent consulter la liste des participant·e·s et y voir leurs données de contact mutuelles. Les données ne sont visibles que dans le contexte « événement », lorsque l’on accède à la personne via la liste des participant·e·s. Dans le contexte d’un « groupe », lorsque l’on accède à la personne via la hiérarchie des groupes, les droits d’accès sont les mêmes que les droits fondés sur la structure ci-dessus.
Cas particulier Contact_Data
Si le rôle d’une personne est classé comme important pour les contacts, cette personne a accès à toutes les autres personnes ayant des rôles importants pour les contacts. Elle est également visible pour toutes les autres personnes ayant des rôles importants pour les contacts. Cela comprend des rôles qui sont souvent en échange avec des personnes d’autres groupes locaux.
Cas particulier finance
Permet de générer et de consulter des factures sur le niveau concerné.
Cas particulier impersonnalisation
Peut reprendre temporairement d’autres comptes, par exemple pour des raisons d’assistance ou des tests. Il s’agit d’une fonction très puissante qui ne devrait être attribuée qu’à des rôles clairement définis.
Security : demandes d’accès et validation manuelle
Supposons qu’Anna souhaite obtenir un accès non autorisé aux données personnelles de John. Pour cela, Anna peut simplement ajouter John dans un groupe, un événement ou un abonnement dans lequel elle a des droits d’accès. Ce problème de protection des données peut être évité dans hitobito grâce aux « validations manuelles ».
Lors de l’ajout de John dans des groupes, des événements et des abonnements, hitobito vérifie le rôle principal de John (celui qui est marqué d’une étoile). Si John n’a plus de rôle actif, hitobito vérifie alors le dernier rôle qui a été actif. Le système vérifie si les validations manuelles sont activées au niveau de ce rôle. Exemple : le rôle principal de John est au sein du groupe de travail « Saturne » de l’association « Sterngucker Luzern ». Les validations manuelles peuvent être activées par niveau (association Sterngucker Luzern) dans l’onglet des demandes.
Si les validations manuelles sont activées dans le niveau, John n’est pas directement ajouté au nouveau groupe, événement ou abonnement inconnu, mais une demande d’accès est envoyée. Anna voit alors le message suivant :
Toutes les personnes concernées par l’onglet demandes, ainsi que John s’il a un login, reçoivent un e-mail les informant qu’Anna veut ajouter John à un nouvel emplacement. La demande d’accès peut être acceptée ou refusée à partir de cet e-mail ou dans l’onglet demandes du groupe.
Ainsi, Anna ne pourra jamais accéder de manière non autorisée aux données personnelles de John. Mais tout cela ne fonctionne que si les validations manuelles sont activées dans le niveau. Aucune demande d’accès n’est déclenchée si Anna a déjà eu accès à John auparavant (par ex. si les deux ont un rôle avec contact_data).