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 d’une réunion,… sur un formulaire d’un projet.
Voici le récapitulatif des rôles locaux sous forme de tableaux :
Remarque
3 rôles locaux sont paramétrables sur demande à l’équipe iA.Vision.
Il est possible d’attribuer aux référents administratifs les droits locaux suivants :
lecteur du projet (par défaut)
contributeur du projet
Il est possible d’attribuer aux partenaires externes les droits locaux suivants :
aucun accès au projet (par défaut)
lecteur du projet
contributeur du projet
Il est possible d’attribuer aux services/départements gestionnaires les droits locaux suivants : ⁻ lecteur du projet (par défaut) ⁻ contributeur 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
Référent administratif d’un projet (rôle paramétrable)
Partenaire externe d’un projet (rôle paramétrable)
Service/personne gestionnaire d’un projet (rôle paramétrable)
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 peur CREER une tâche si il a des droits globaux suffisants ou locaux de contiributeur/éditeur sur le projet parent.
un utilisateur peut MODIFIER une tâche si il a des droits globaux suffisants ou locaux de contiributeur/é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 suffisant 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 raisonx 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.