Permissions JIRA sur les types de demande avec nFeed


Publié par
Nicolas ESTEVES

23 janvier 2015

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.

  • Nicolas Esteves

    Bonjour Vinsen,

    Votre besoin n’est pas directement lié à l’article, mais voici un premier élément de réponse.

    Par défaut, si un utilisateur est apte à voir une demande, alors il peut voir tous les champs de la demande. On ne pourra pas changer ce comportement; on ne peut configurer un niveau de sécurité sur des champs.

    En revanche, à l’aide d’un plugin nommé Behaviour (embarqué dans Script Runner), on est capable de bloquer l’édition de certains champs, à certains utilisateurs. Je pense donc que cette solution peut couvrir au moins la deuxième partie de votre besoin. Je vous encourage donc à creuser dans cette direction.

    PS: Sinon, si vraiment certains informations d’une demande ne doivent pas être consultables par certains, il peut être intéressant de créer un autre type de demande (« Infos complémentaires » par exemple), et de créer une demande de ce type là liée à la demande initiale via Exocet par exemple, et faire en sorte que cette demande ne soit pas visible par tout le monde. Contrairement aux champs, on est bel et bien capable de mettre des niveaux de sécurité sur des demandes.

    PS2: Si vous souhaitez de l’assistance pour un tel paramétrage, n’hésitez pas à vous rapprochez de Valiantys et je serai ravi de vous aider.

    Cordialement,
    Nicolas.

  • VINSEN THAMBOO

    Bonjour,

    Comment fait-on pour personnaliser la « vue » d’un utilisateur ?
    J’entends par là personnaliser l’interface d’un utilisateur, ne pas lui permettre la saisie d’informations dans un champ en particulier etc
    Cordialement
    Mr THAMBOO

  • Nicolas Esteves

    Bonjour Pierre-Jean,

    Je comprends ce que vous voulez dire, mais ce n’est pas tout à fait exact. La fonctionnalité apportée par Issue Security Scheme permet de rendre des demandes invisibles/visibles pour certaines populations, en fonction d’utilisateurs, de groupes, ou de rôles définis dans des niveaux.

    La fonctionnalité supplémentaire amenée par nFeed est de pouvoir faire varier ces paramètres (dans l’exemple ci-dessus, les utilisateurs puis les groupes) en fonction d’un autre paramètre; l’Issue Type. Selon ce dernier, la valeur du champ nFeed renverra une population spécifique. Ce même champ peut ensuite être utilisé dans le Permission Scheme (comme dans l’exemple), ou bien dans un Issue Security Scheme.

    En espérant vous avoir correctement répondu. N’hésitez pas si vous avez des questions supplémentaires.

    Cordialement,
    Nicolas.

  • Pierre-Jean Constant

    Bonjour,

    Est-ce qu’il ne s’agit pas d’une manière détournée de reproduire la fonctionnalité d’un « Issue Security Scheme » ?

    Bàv