Aller directement à la fin des métadonnées
Aller au début des métadonnées

1- Matrice


Le système de droits & rôles est basé sur une matrice. Cette matrice gère, d'un côté, les droits, et de l'autre, des utilisateurs et permet de gérer les affectations.

1-1 Les droits:

Afin de gagner en visibilité, nous avons structuré les droits (access_rights) de façon à pouvoir les catégoriser et permettre ainsi de les regrouper dans des zones (access_area).

1-2 Les utilisateurs:

Afin de faciliter la gestion des droits, nous avons mis en place un système de rôle. Chaque rôle pourra contenir 1 ou plusieurs utilisateurs, par contre, un utilisateur ne pourra avoir qu'un et un seul rôle.
A chaque rôle sera ensuite affecter une liste de droits auxquels tous les membres du rôles auront accès. Certains droits pourront néanmoins être définis comme 'ouverts', et seront donc à accorder ou non au cas par cas à chaque membre du rôle.

Par défaut, un rôle n'a aucun droit d'ouvert.

Un rôle peut néanmoins 'hériter' d'un rôle parent, en quel cas, les droits du parents lui seront automatiquement accordés et pourront ensuite être retirés. Par contre, aucun droit supplémentaire ne pourra être ouvert tant que le rôle parent n'y a pas accès. 

NOTA: le rôle supadmin est un faux rôle dans le sens où on peut l'affecter, mais il n'est pas modifiable: ses membres auront, par défaut, tous les droits.

 

2- Contextes Forum


Certains droits peuvent être défini comme pouvant être limité à une certaine partie du site. Par exemple, nous pouvont donner un droits de modération à une personne, mais uniquement sur certaines catégories du forum. Il s'agit de contextes.

Ils sont définissables dans la popup d'édition d'un membre de l'équipe depuis le BO. Un contexte peut être null (nulle part), partiel (et l'on choisi tout un forum, ou certaines catégories de certains forums) ou total (toutes les catégories de tous les forums).

 

3- Développement: vérifications des droits (application)


Des méthodes sont mises à dispositions afin de tester les droits d'accès d'un utilisateur ($viewer).

La principale est CF_user::has_access_to($right_name, $forum_context = null, $at_least = null).
Pour avoir accès, l'utilisateur doit:

  • être connecté (on teste ça sur le $viewer pour être sûr)
  • avoir accès au droit demandé (grâce à son rôle, ou parce que le droit lui a explicitement été ouvert): un utilisateur standard du site retournera donc toujours false (car pas d'access_role, et du coup, évidemment, aucun droit spécifique).
  • si l'on est dans un contexte forum alors on le précise et dans ce cas, l'utilisateur doit également être déclaré dans le contexte en question ($at_least sert à spécifier si le contexte est un $forum, si l'accès à une seule catégorie est suffisante pour ouvrir le droit ou s'il faut un accès à toutes les catégories du forum): cela peut-être utile, par exemple, si l'on veut afficher certaines fonctionnalités de modération sur une page du forum, ou si l'on recherche la listes des modérateurs du forum (toutes catégories confondues, en quel cas, $at_least peut-être forcé à true (clin d'œil)).

L'autre fonction est ensuite CF_user::editable($what = 'add_medias', $owner_allowed = true, $useless = '') ou CF_group::editable($what = 'add_medias', $owner_allowed = true, $zone = '') ou encore CF_blog::editable($what = 'add_medias', $owner_allowed = true)
Ces fonctions ont l'avantage de pouvoir accorder un droit aussi bien à la personne ayant le droit spécifique demandé qu'au propriétaire de l'objet en question. Ce qui est trè pratique quand on veut savoir qui peut modifier les paramètres d'un compte utilisateur ou encore d'un groupe ou d'un blog. Mais elles sont également très utililes si l'on ne veux pas donner le droit au propriétaire de l'objet, mais permettre au développeur de tester le nom du droit de manière dynamique. Par ex., si l'on veut savoir qui peut justement éditer les paramètres. Chacun des objets ont un droits 'user_edit_params', 'group_edit_params' et 'blog_edit_params'. Grâce à cette fonction, le développeur peut avoir des scripts génériques et ne pas se soucier de savoir dans quel cas il se trouve: $owner->editable('edit_params', false) et la fonction se charge de tester le bon droits en rajoutant le préfix qui va bien à l'objet appelé.
Pour avoir accès, l'utilisateur doit:

  • être connecté
  • être le propriétaire de l'objet si $owner_allowed = true (ou un admin si l'objet est un groupe) OU avoir accès au droit demandé (grâce à son rôle, ou parce que le droit lui a explicitement été ouvert)

4- Liste des autorisations délivrables par défaut à ce jour

 

Back-office

Le back-office vous permet d'autoriser ou non chaque groupe d'utilisateurs (rôles) aux droits correspondants. Vous pouvez également voir quels utilisateurs sont présents dans quels groupes, ...

  • Aucune étiquette