Beaucoup d’utilisateurs de JIRA soulignent un réel manque au niveau des permissions que l’outil propose. En effet, en l’état actuel des choses, il est impossible de spécifier nativement des permissions par types de demande – ce qui pourtant serait bien utile, comme par exemple avec la permission “Parcourir les projets”; comment dans ce cas affecter cette permission à un type de demande, ou mieux, à certaines personnes au sein d’un même projet? A première vue, cela ne semble pas possible.
Des soucis de visibilité voire de confidentialité peuvent donc rapidement poser problème lorsqu’ils n’ont pas été anticipés. Une restructuration d’un ou plusieurs projets JIRA peut même s’avérer nécessaire pour segmenter le contenu. Néanmoins, différentes solutions de contournement existent, mais la plupart sont assez complexes à mettre en place et pas forcément des plus pérennes.
Nous allons donc ici voir comment pallier à ce manque avec une méthode simple et rapide qui repose sur une des multiples et possibles utilisations de l’add-on nFeed.
Cas d’utilisation
Pour le projet “Valiantys – Support”, l’utilisateur “Administrateur” possède toutes les permissions sur le projet et peut donc voir logiquement toutes les demandes. Cependant, il aimerait pouvoir autoriser l’utilisateur “Nicolas” à consulter uniquement les demandes de type “Nouvelle fonctionnalité”, et “Jeremie” à consulter seulement les demandes de type “Bug”.
Types de demande du projet: Bug, Amélioration, Nouvelle fonctionnalité, Tâche
Utilisateurs: Administrateur, Nicolas, Jeremie
Objectifs: “Administrateur” peut voir toutes les demandes (déjà en place), “Nicolas” seulement celles de type “Nouvelle fonctionnalité”, et “Jeremie” seulement celles de type “Bug”.
Comment paramétrer nFeed et JIRA
Pour atteindre les objectifs, seulement 4 étapes sont nécessaires.
Etape 1 – Créer un champ personnalisé de type “nFeed – Users”
Nous l’appellerons “Permission accordée à”. Noter son ID car il servira plus tard (visible dans la configuration nFeed; 10242 dans notre cas).
Ajouter ce nouveau champ personnalisé aux écrans de vue pour tous les types de demandes concernés.
“Generic – OP – Vue SCR”.
Etape 2 – Créer une configuration nFeed pour ce champ
Onglet “Paramètres généraux”:
Onglet “Saisie”:
Pour cette partie là, il est important de connaître les ID des types de demande et des utilisateurs concernés. Dans notre exemple:
- Bug : ID = 1
- Nouvelle fonctionnalité: ID = 2
- Nicolas: ID = 10207
- Jeremie: ID = 10208
Pour les utilisateurs, il est nécessaire d’aller voir dans la base de données. La table concernée se nomme “cwd_user”. A savoir qu’il est également possible de faire une requête en utilisant seulement le “user_name”, mais cette solution n’est pas à privilégier.
Ce qui nous intéresse ici est bien entendu la requête. Pour chaque type de demande, sélectionner l’utilisateur souhaité.
#
if ($issue.issueType.id==2)
select
user_name
from
cwd_user
where
id=10207
#elseif ($issue.issueType.id==1)
select
user_name
from
cwd_user
where
id=10208
#
end
Ne pas oublier de sélectionner le résultat unique automatiquement. Pour cela, cliquer sur le bouton “Configurer” pour accéder aux options avancées:
Enfin, sauvegarder la configuration.
Etape 3 – Fixer automatiquement la valeur du champ nFeed
Pour cela, il va falloir utiliser une fonction de publication. Les transitions concernées sont toutes les transitions “Create Issue” des workflows associés aux types de demandes en question. Sur celles-ci, il est nécessaire de rajouter une fonction de publication fournie par nFeed.
Celle qui nous intéresse se nomme: “Affecter une valeur à un champ nFeed”. Indiquer en paramètre de la fonction l’ID précédemment noté, servant à identifier notre champ nFeed “Permission accordée à”.
Grâce à cette manipulation, lors de chaque création d’une demande de type “Nouvelle fonctionnalité” ou “Bug”, le champ nFeed présent sur l’écran de vue prendra dynamiquement la valeur de la personne concernée à autoriser, sans avoir à le placer sur l’écran de création.
Etape 4 – Utiliser le champ nFeed pour affecter des permissions
Enfin, il est nécessaire d’affecter la permission “Parcourir les projets” au champ “Permission accordée à” dans le système d’autorisation utilisé par le projet “Valiantys – Support”.
Ainsi, l’utilisateur aura bien la permission de voir les demandes du projet seulement pour le type de demande qui lui est associé.
Résultat
L’utilisateur “Administrateur” a créé deux demandes, une de chaque type:
Lorsque l’utilisateur “Nicolas” se connecte, il ne peut voir que celles de type “Nouvelle fonctionnalité”:
Au contraire, l’utilisateur “Jeremie” ne peut voir que les demandes de type “Bug”:
L’objectif est atteint. Avec nFeed, il est donc facilement possible d’améliorer l’expérience JIRA en parvenant à affiner les permissions suivant le besoin. Et ce n’est qu’un exemple parmi tant d’autres!
Pour aller plus loin
Nous avons vu un cas simple, où l’on utilise un champ de type “nFeed – Users” pour donner une permission à un utilisateur en particulier selon des conditions (ici, les types de demandes). Cependant, il est aussi possible d’étendre cette astuce à des groupes. Pour cela, il est nécessaire d’utiliser un champ de type “nFeed” (nommé “Permission accordée à (groupe)” dans l’exemple qui suit).
La seule différence va se faire au niveau de la requête. Au lieu de remonter un utilisateur, le champ va devoir aller chercher un groupe.
- jira-administrators: ID = 10000
- jira-developers: ID = 10001
- jira-users: ID = 10002
#
if ($issue.issueType.id==2)
select
group_name
from
cwd_group
where
id=10002
#elseif ($issue.issueType.id==1)
select
group_name
from
cwd_group
where
id=10001
#
end
Comme précédemment, il est nécessaire d’ajouter ce nouveau champ dans le système d’autorisation:
Logiquement, cette fois-ci le champ est à aller chercher dans “Valeur du champ personnalisé de groupe” et non pas “Valeur de champ personnalisé d’utilisateur”.
Résultat
Les demandes de type “Nouvelle fonctionnalité” seront visibles par tout le monde, alors que les demandes de type “Bug” ne seront visibles que par les développeurs.
Vous savez désormais comment utiliser un champ nFeed de manière dynamique sur une permission. Cette astuce vous évitera de devoir vous lancer dans des actions de plus grande envergure pour segmenter le contenu d’un projet JIRA et vous permettra donc de gagner un temps précieux! Vous pouvez vous faire votre propre idée de l’outil en l’essayant gratuitement.