Permissions JIRA, nFeed
  • Article
  • 23.Jan.2015

Permissions JIRA sur les types de demande avec nFeed

  • 23.Jan.2015
  • Temps de lecture mins

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”.

Projet: Valiantys – Support

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.

Dans notre cas, il s’agit d’un seul écran pour les deux types de demandes:

“Generic – OP – Vue SCR”.

1

Etape 2 – Créer une configuration nFeed pour ce champ

Onglet “Paramètres généraux”:

2

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 récupérer les types de demandes, il suffit d’aller dans “Administration” > “Demandes” > “Types de Demandes”, et de repérer les ID dans les URL du bouton “Modifier” de chaque type.

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.

3

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:

4

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 à”.

5

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.

Dans notre cas, le workflow étant le même pour les deux types de demande, la manipulation n’est à faire qu’une seule fois.

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”.

6

Ainsi, l’utilisateur aura bien la permission de voir les demandes du projet seulement pour le type de demande qui lui est associé.

Il est également possible d’utiliser ce champ sur d’autres permissions.

Résultat

L’utilisateur “Administrateur” a créé deux demandes, une de chaque type:

7

Lorsque l’utilisateur “Nicolas” se connecte, il ne peut voir que celles de type “Nouvelle fonctionnalité”:

8

Au contraire, l’utilisateur “Jeremie” ne peut voir que les demandes de type “Bug”:

9

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.

Pour récupérer les ID des groupes, il est nécessaire d’aller voir dans la base de données. La table concernée se nomme “cwd_group”. ID des groupes JIRA par défaut:

  • 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:

10

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.

Essayez nFeed gratuitement

Ressources complémentaires

Voir toutes les ressources