Sortie d’une custom field JIRA : hakanai-cascading-select

Récemment j’ai eu besoin d’utiliser une liste en cascade avec sélection multiple dans JIRA. Malheureusement, s’il existe bien un système de sélection en cascade, celui-ci ne permet pas la sélection multiple.

Du coup j’ai du créer un custom field en repartant du Custom field original.

Un petit exemple en image ?

Ci-dessous en mode édition la valeur « Développement » a été sélectionné dans la première liste. Plusieurs valeurs sont sélectionnées dans la seconde :

32624

En voilà ce que ça donne en mode visualisation (la valeur principale en gras, les valeurs secondes en enfilade derrière) :

32626

 

Envie de tester par vous-même ? C’est ici.

 

Atlassian User Group Paris 2010

Plus de détails ici sur l’annonce de l’évènement : Atlassian User Group

Voilà, de retour du Atlassian User Group de Paris. La conférence était organisé par Valiantys, partenaire français d’Atlassian.
Cette conférence regroupait une vingtaine de personnes et avait pour but de promouvoir l’utilisation de la suite Atlassian en tant que plateforme ALM. Comme le portefeuille Atlassian est assez important et que la conférence ne durait qu’une demi journée, c’est surtout JIRA qui a été abordé.

Vous voulez en savoir plus, c’est par ici.

L’agenda de cette demi-journée était organisé comme suit :

13:30     Accueil/Café
14:00     Introduction (Valiantys)
14:15 JIRA & GreenHopper New releases (Atlassian)
14:45     Retour d’expérience JIRA     Agrostar (STEF-TFE)
15:30     Balsamiq Mockups for JIRA     Balsamiq
16:00 Pause
16:30 Retour d’expérience JIRA     ADP GSI
17:15     Tables rondes en simultanées

  • Performances JIRA (Atlassian)
  • Les plugins de références (Valiantys)
  • GreenHopper (Valiantys)

18:00     Discussion ouverte et Apéritif

Premier point positif, en arrivant dès le début j’ai pu échanger un peu avec les organisateurs et les personnes d’Atlassian présentes. Très intéressant car la suite de produit Atlassian est vendu en ligne et aucun « vendeurs » Atlassian n’a l’habitude de venir discuter avec les petits froggies. De plus c’était pour moi l’occasion de découvrir l’activité des partenaires Atlassian.

… 

 

Sortie d’un plugin Jira : jira-order-plugin

J’avais déjà parlé de Jira et des possibilités de personnalisation dans un précédent article. Ici plus exactement.

Cette fois-ci c’est un nouveau plugin que je sors des cartons, Jira order plugin, une fille d’attente pour gérer des fiches par ordre de priorité.

 

Principe de fonctionnement

Pour résumer, le principe de ce plugin est assez simple, il permet de créer une file d’attente des fiches à traiter.

Mais pourquoi une file d’attente alors qu’on a déjà une priorité sur les fiches me direz-vous ? Ne vous est-il jamais arrivé d’avoir 200 fiches ouvertes dans votre projet avec 20 fiches à traiter d’urgence sans parler du reste ? Ok et dans ce cas là quelle est votre stratégie ? Traiter toutes les demandes urgentes d’un coup ? Les traiter dans un ordre aléatoire ?

Parfois on voit des managers qui vont de nouveau reprioriser leur fiches urgentes avec des priorités « urgentes ++ » en créant donc un nouveau stade d’urgence. Bon super, et après, on créé un « urgente +++ », « plus urgente tu meurs » etc… L’autre idée c’est de définir leur ordre de traitement de façon linéaire à travers une file d’attente.

Mais bon, pas envie de gérer sans arrêt les ajouts dans la file d’attente, dans ce cas le plugin va calculer automatiquement la position d’une nouvelle fiche entrée dans le système à partir de sa priorité et de sa date de création. Et voilà, vous avez les grandes lignes directrices de ce plugin :

  • file d’attente des fiches à traiter
  • calcul de la position initiale des fiches dans la file à partir de leur priorité et de la date de création
  • recalcul de la position des fiches dans la file après un déplacement ou un changement d’état

Concrètement la visualisation de cette file d’attente utilise le navigateur de fiches :

issueorder

On remarquera sur l’image la colonne « Issue ordering » qui représente notre Custom field configuré pour apparaître dans le navigateur de fiches.

Et sous le capot, ça marche comment ?

Plus complexe que le précédent plugin, cette fois-ci il s’agit :

  • d’un custom field
  • d’un listener qui écoute les changements d’états des fiches
  • d’un service qui réordonne les fiches régulièrement
  • d’une action webwork combiné avec Jquery pour un réarrangement manuel de l’ordre des fiches

Jquery

Parmi les éléments techniques intéressants ici je citerais notamment l’utilisation de Jquery pour la partie Drag and drop qui permet de repositionner les fiches manuellement.

Dans le template Velocity j’utilise un bout de code Jquery pour chaque valeur de champ

?View Code JAVASCRIPT
$('#rankHkn${index}').draggable({ axis: 'y', cursor: 'crosshair', opacity: 0.35, revert: true });
$('.droppable').droppable({drop: function ( event, ui) {displayMessageOrderField(ui.draggable.attr("id"),this); }});

Et voilà, en deux lignes à peine j’obtiens la possibilité de faire du Drag and Drop sans être vraiment expert JavaScript moi-même ^^

On notera que ${index} est interprété par Velocity lors de la création de la page, alors que $(‘.droppable’) n’ayant pas été interprété par Velocity, il apparaît tel quel dans la page HTML et sera donc utilisé comme sélecteur CSS par JQuery. L’utilisation du $ dans les templates Velocity pour deux choses distinctes peut amener bien des surprises si on n’y fait pas gaffe.

Un petit brin d’ergonomie, évitez l’attente

Vous vous souvenez, plus haut j’ai écrit que les fiches étaient automatiquement placés dans la file d’attente lors de leur création en fonction de certains critères. Ok mais du coup ca implique un calcul. Rapide sur une petite instance, ce calcul peut facilement prendre du temps sur une instance Jira avec un grand nombre de fiches. Et ce temps on veut éviter de l’infliger à l’utilisateur qui voulait juste créer une fiche, lui.

Toute l’astuce a donc été ici d’utiliser un design pattern assez simple, le producteur consommateur :

  • le producteur c’est l’utilisateur, à la création d’une fiche (ou sa modif) il empile l’action dans une file d’évènement
  • le consommateur c’est un service Jira qui dépile cette file pour traiter les évènements

Du coup, pas d’attente pour l’utilisateur car l’ajout dans la pile est rapide. Le défaut c’est par contre d’avoir une actualisation de la position dans la file d’attente plus lente, après le passage du service uniquement.

Et côté implémentation en Java, rien de mieux que l’utilisation d’une BlockingQueue qui permet de gérer correctement la concurrence d’accès à l’ajout et la lecture dans la pile.

Où trouver tout ça

Bon, si le plugin vous intéresse, vous pouvez le trouver sur le plugins exchange ou sur sa page Confluence.

Et si le code vous intéresse, celui-ci est accessible via svn ici.

 

 

Sortie d’un custom field Jira : jira-status-color

Mais c’est quoi Jira ?

Pour ceux qui ne connaissent pas encore Jira, il s’agit d’un excellent BugTracker édité par la société Atlassian. Très bon en entreprise via ses différents plugins, sa gestion du temps, son plugin Scrum (Greenhopper) il est aussi accessible pour des structures plus petites avec une license à 10$. En fait si vous faites du Java, vous l’avez surement déjà vu puisqu’il s’agit du BugTracker utilisé par une grande partie des projets open sources.

Bref, je vais éviter de m’étendre dessus après on va croire que je touche des dividendes ^^ Revenons à l’aspect technique donc. Jira fait partie de ces logiciels qui proposent d’écrire ses propres extensions et c’est d’ailleurs une de ces grandes forces quand on voit la quantité de plugins disponibles sur leur site. Ayant quelques plugins dans les cartons qui devraient sortir d’ici peu, je me permets d’en faire une petite pub ici.

Et c’est quoi un custom field ?

Un custom field c’est un champ personnalisé (non sans blague) qui peut être rempli automatiquement ou par l’utilisateur et qui peut aussi apporter du comportement, dans notre exemple une coloration. Les champs personnalisés peuvent aller du plus basique : liste de choix, bouton radio etc… jusqu’au plus complexe : champs qui stocke le temps moyen passé sur une fiche dans ses différents status par exemple.

Jira Status color

kesako ?

Tout le but de ce custom field c’est d’ajouter un indice visuel permettant d’identifier rapidement le statut de la fiche. La demande est venu d’anciens collègues qui avaient bossé sur un autre bugtracker qui différenciait les status des fiches par couleur. Et c’est vrai qu’au final c’est intéressant d’avoir en un coup d’oeil ce type d’indications.

(Evidemment on ne parlera pas ici d’accessibilité puisqu’un daltonien n’aura aucun intérêt à l’utiliser)
On pourrait dire « rien de transcendant finalement ton truc », mais comme on dit , « c’est inutile donc indispensable ».

Un exemple dans le navigateur de fiche :

issuenavig

Et sur la fiche elle-même :

view

Si ça vous intéresse, vous pourrez le trouver dans le centre d’échange des plugins : Plugins exchange

Ou bien sur sa page de wiki directement pour en savoir plus sur son installation, ses bugs connus etc…