Les rôles locaux#
Comme précisé précédemment, ces rôles sont conférés par l’application lorsque le contact est référencé comme référent administratif, référent politique, chef de projet, membre d’une équipe projet, créateur du projet,… sur un formulaire d’un projet.
Voici le récapitulatif des rôles locaux configurés par défaut sous forme de tableaux#
Attention, le rôle local défini pour un champ est appliqué pour toute l’application et non l’un ou l’autre formulaire isolé.
Paramétrage des rôles locaux#
Tous les rôles locaux sont paramétrables sur demande à l’équipe iA.Vision, via un ticket de support : cliquez ICI
Pour chacun des rôles, il y 4 possibilités de configuration :
aucun accès au projet
lecteur du projet
contributeur du projet
éditeur du projet
Quelques précisions quant aux termes utilisés pour les rôles locaux :
L’“Éditeur local” a une édition totale sur le projet sur lequel il porte, avec une lecture uniquement sur le libellé de l’OO lorsque le projet est lié au PST s’il n’a aucun rôle complémentaire sur le module Gestion du PST.
Chef d’un projet
Créateur d’un projet
Le “Contributeur local” dispose des droits de lecture sur le projet sur lequel il porte et droits d’édition sur les objets enfants du projet (tâches, mesures des indicateurs existants,…). Il ne peut pas modifier les informations du projet lui-même.
Membre de l’équipe d’un projet
Le Créateur de réunion est Éditeur local de la réunion, il peut donc modifier toutes les informations de celle-ci.
Le Participant à une réunion est Éditeur local de la réunion également.
Remarque:
Aucun rôle local n’existe pour un Contact assigné à une tâche en tant que tel :
un utilisateur peut VISUALISER une tâche si il a des droits globaux suffisants ou locaux de lecture sur le projet parent/est assigné sur la tâche/est assigné sur la tâche parent.
un utilisateur peut CRÉER une tâche si il a des droits globaux suffisants ou locaux de contributeur/éditeur sur le projet parent.
un utilisateur peut MODIFIER une tâche si il a des droits globaux suffisants ou locaux de contributeur/éditeur sur le projet parent.
un utilisateur peut SUPPRIMER une tâche si il a des droits globaux d’administration du module.
un utilisateur peut ARCHIVER une tâche si il a des droits globaux suffisants ou s’il a les droits d’éditeur sur le projet parent.
==> être assigné à une tâche ne suffit donc pas pour ‘manipuler’ la tâche, il faut des droits sur le projet parent. A défaut, l’assignation est à titre informatif.
Ex. de cas d’usage : une tâche est assignée à une personne tierce qui ne doit pas avoir accès à l’application pour une raison x ou y (SPW, CPAS, etc) mais le chef de projet de la Ville veut matérialiser la tâche et en faire lui-même le suivi/l’actualiser.
Remarque : aucun rôle local ne permet d’archiver / désarchiver un objet, seuls les rôles globaux le permettent.