Gérer les bugtrackers et serveurs de synchronisation

Bugtrackers vs serveurs de synchronisation

Dans Squash, il faut distinguer les plugins de bugtracking des plugins dédiés aux synchronisations. Les plugins de bugtracking servent à la déclaration d'anomalies depuis Squash vers des outils tiers de type Bugtracker.
Les plugins de synchronisation servent à synchroniser dans Squash des tickets présents dans des outils tiers dédiés au suivi de projets IT.

Voici la liste des outils tiers avec lesquels peut s'interfacer Squash :

Nom du plugin	Catégorie	Type dans l'espace Serveurs	Outils tiers
Mantis REST Bugtracker	Bugtracking	mantis	Mantis
Bugzilla Bugtracker	Bugtracking	bugzilla	Bugzilla
GitLab Bugtracker	Bugtracking	gitlab.bugtracker	GitLab
Jira Bugtracker Server et Data Center	Bugtracking	jira.rest	Jira Server, Jira Data Center
Jira Bugtracker Cloud	Bugtracking	jira.cloud	Jira Cloud
Xsquash4Jira	Synchronisation	jira.xsquash	Jira Server, Jira Data Center, Jira Cloud
Workflow Automatisation Jira	Synchronisation	jira.rest ou jira.cloud	Jira Server, Jira Data Center, Jira Cloud
Redmine Bugtracker	Bugtracking	redmine3.rest	Redmine
Redmine Exigences	Synchronisation	redmine3.rest	Redmine
Azure DevOps Bugtracker	Bugtracking	azuredevops.bugtracker	Azure DevOps
RTC Bugtracker	Bugtracking	rtc	Rational Team Concert
Tuleap Bugtracker	Bugtracking	tuleap	Tuleap

Il nécessaire d'installer le ou les plugin(s) correspondant(s) à l'outil pour accéder aux fonctionnalités de bugtracking ou de synchronisation. Certains plugins sont embarqués dans la distribution de Squash.
Pour en savoir plus sur les plugins, consulter les pages suivantes : Les plugins de Squash, Installer les plugins Squash.

Ajouter, modifier, supprimer un bugtracker et un serveur de synchronisation

La gestion des bugtrackers et serveurs de synchronisation est accessible depuis l'espace Administration, sous-menu Serveurs, via l'ancre Bugtrackers et serveurs de synchronisation .

Depuis le tableau de gestion des bugtrackers et serveurs de synchronisation, il est possible d'ajouter ou de supprimer des serveurs de façon unitaire ou en masse. Il est également possible de supprimer un bugtracker ou un serveur de synchronisation depuis sa page de consultation en cliquant sur le bouton [...].

Tableau de gestion des bugtrackers et serveurs de synchronisation

Lors de la création d'un bugtracker ou d'un serveur de synchronisation, il faut renseigner un nom (libre), choisir le type de serveur dans la liste déroulante et renseigner l'URL de l'outil tiers. L'URL doit être la plus courte possible car elle sert de base à toutes les requêtes API utilisées par Squash pour communiquer avec l'outil tiers. Tous ces champs sont obligatoires.

Pop-up création BT ou serveur de synchro

En cliquant sur le numéro de ligne (#) ou le nom, la page de consultation du serveur s'affiche pour permettre sa modification. La barre des ancres permet de naviguer entre les différents blocs.

Page de consultation BT ou serveur de synchro

Attention

Lorsqu'un serveur de bugtracking est supprimé, il est automatiquement supprimé du projet auquel il était associé. La valeur "Pas de bugtracker" s'affiche sur la page de consultation du projet.
Toutes les associations avec les anomalies présentes dans les blocs Anomalies connues sont également supprimées.

Paramétrer un bugtracker ou un serveur de synchronisation

Pour qu'un bugtracker accepte d'échanger des informations avec Squash, ce dernier doit s'authentifier. La gestion de l'authentification permet de définir de quelle façon les utilisateurs ou Squash lui-même vont s'authentifier sur le serveur. Elle se décompose en deux blocs :

le bloc Protocole d'authentification qui définit le protocole de sécurité utilisé pour authentifier la connexion ;
le bloc Politique d'authentification qui détermine de quelle façon les utilisateurs et/ou Squash sont authentifiés.

Protocole d'authentification

Le bloc Protocole d'authentification permet de définir le protocole d'authentification. Les protocoles supportés par Squash sont "Basic Authentication", "OAuth 1A" (uniquement pour les connecteurs Jira), "OAuth 2.0" (uniquement pour les connecteurs Jira) et "Token Authentication" (uniquement pour les connecteurs GitLab, Mantis et Redmine). Les protocoles proposés à la configuration dépendent du type de bugtracker.

Focus

Lorsque l'on change le protocole d'authentification, l'effet est appliqué immédiatement. La configuration précédente est rendue obsolète et supprimée du serveur. Cependant les informations restent présentes dans la page tant que la page n'est pas fermée ou rafraîchie : si le protocole est modifié par erreur, il est possible de rétablir le protocole précédent et de sauvegarder à nouveau la configuration.

Basic Authentication

Basic Authentication est le protocole par défaut. L'authentification s'appuie sur la saisie du login et du mot de passe de l'utilisateur. Il est supporté par tous les serveurs sauf GitLab et Mantis. Il ne requiert pas de configuration supplémentaire. L'usage de Basic Authentication n'est considéré comme sécurisé qu'en conjonction avec SSL/TLS (https).

Jira Cloud

Jira Cloud nécessite un API Token à la place du mot de passe habituel pour se connecter bien que le protocole Basic Authentication soit utilisé.
Quelle que soit la politique d'authentification choisie, dans le champ Login, il faut renseigner l'adresse mail de l'utilisateur, et, dans le champ Jeton, renseigner le jeton généré pour le compte sur Jira Cloud.
La procédure à suivre pour générer un jeton est détaillée sur cette page : Créer un jeton d'API.

Azure DevOps

Azure DevOps nécessite un API Token à la place du mot de passe habituel pour se connecter bien que le protocole Basic Authentication soit utilisé.
Quelle que soit la politique d'authentification choisie, dans le champ Nom de l'organisation, il faut renseigner le nom de l'organisation Azure DevOps, et dans le champ Jeton, renseigner l'API token généré pour le compte de l'utilisateur sur Azure DevOps. Des droits Read & Write sur les Work Items sont suffisants.
La procédure à suivre pour générer un token est détaillée sur cette page : S'authentifier avec des jetons d'accès personnels dans Azure DevOps.

OAuth 1A

Ce protocole n'est pour l'instant exploité que par les connecteurs Jira. Il nécessite de configurer les URLs impliquées dans l'échange de jetons et les modalités de signature des requêtes. Les champs à renseigner dans le bloc Politique d'authentification sont un jeton et le secret du jeton.

Pour en savoir plus, consulter la page Configurer le protocole d'authentification OAuth 1A.

OAuth 2.0

Ce protocole n'est pour l'instant exploité que par les connecteurs Jira. La configuration se fait à la fois dans Jira et dans Squash. Elle diffère selon le mode d'hébergement de Jira (Jira Server/Data Center ou Jira Cloud).

Pour en savoir plus, consulter la page Configurer le protocole d'authentification OAuth 2.0.

Token authentication

Ce protocole n'est pour l'instant exploité que par GitLab, Mantis REST et Redmine. L'authentification s'appuie sur la saisie d'un jeton généré dans l'outil tiers et ne requiert pas de configuration supplémentaire.

GitLab

Pour générer un jeton sur GitLab, consulter la page Personal access tokens.

Mantis

Pour générer un jeton d'API Mantis, rendez-vous dans Mon compte (1), puis dans l'onglet Jetons de l'API(2).

Générer un jeton dans Mantis

Donner un nom explicite au Jeton afin de le révoquer si besoin (3), puis cliquer sur le bouton [Créer un jeton de l'API] (4) pour le créer.
Copier le jeton généré et le coller dans le champ Squash prévu à cet effet selon la politique d'authentification choisie.

Redmine

Pour générer un jeton d'API sur Redmine, rendez-vous dans Mon Compte (1) puis afficher la Clé d'accès API (2).

Générer un jeton dans Redmine

Copier le jeton généré et le coller dans le champ Squash prévu à cet effet selon la politique d'authentification choisie.

Politique d'authentification

Le bloc Politique d'authentification permet de configurer le choix d'authentification des utilisateurs pour le bugtracker ou le serveur de synchronisation.

Politique d'authentification d'un serveur/bt

Les utilisateurs s'identifient eux-mêmes : chaque utilisateur doit s'identifier personnellement à l'outil tiers. La procédure varie suivant le protocole choisi. Dans le cas d'une Basic Authentication, il doit saisir son login et mot de passe de connexion à l'outil tiers dans Squash, tandis que pour une Token Authentication, il doit saisir un jeton d'accès généré dans l'outil tiers. Pour OAuth 1A, l'authentification est déléguée au serveur tiers dans une fenêtre distincte ;
Utiliser les identifiants du compte technique du serveur : les utilisateurs n'ont plus à s'authentifier et le serveur utilise automatiquement les identifiants d'accès à l'outil tiers renseignés dans le champ Identifiants du compte technique de nom_du_serveur. Quel que soit l'utilisateur connecté dans Squash, les données sont remontées vers l'outil tiers avec les identifiants de l'utilisateur renseigné dans le bloc.

Info

L'option Les utilisateurs s'identifient eux-mêmes est conseillée pour la configuration des bugtrackers. Le nom de l'utilisateur est ainsi renseigné comme rapporteur de l'anomalie, à la place d'un utilisateur commun. Cela permet d'avoir une traçabilité des échanges entre l'outil tiers et Squash.
L'option Utiliser les identifiants du compte technique du serveur peut être utilisée lors de la configuration d'un serveur de synchronisation, notamment pour Xsquash4Jira et Xsquash4GitLab si l'on souhaite effectuer les synchronisations avec un compte technique, ainsi que le plugin Workflow Automatisation Jira.

Le champ Identifiants du compte technique de nom_du_serveur est à renseigner uniquement si l'option Utiliser les identifiants du compte technique du serveur est cochée.

Pour que les champs soient enregistrés en succès, il faut que :

l'outil tiers soit joignable ;
les identifiants de connexion à l'outil tiers soient corrects ;
le compte associé à ces identifiants dispose des permissions nécessaires sur l'outil tiers ;
la configuration du serveur soit correcte.

Info

Squash persiste en base de données certaines informations concernant l'authentification. Ceci inclut la configuration de protocole, les identifiants applications de Squash et les jetons OAuth des utilisateurs le cas échéant. Les logins et mots de passe personnels des utilisateurs (Basic Authentication) sont sauvegardés chiffrés dans la base de données.

Configuration du cache

Pour le bugtracker GitLab, le bloc Configuration du cache permet de configurer un cache qui stocke les valeurs utilisées pour la déclaration d'anomalie, telles que les labels, les utilisateurs et les jalons. Ce cache permet de réduire le nombre de requêtes envoyées au serveur GitLab.

Pour configurer le cache, saisir le jeton utilisé pour générer le cache. Il doit avoir au moins des droits de lecture sur les issues des projets GitLab liés aux projets Squash pour la déclaration d'anomalies. Le panneau "Contenu du cache" affiche les données actuelles du cache.

Par défaut, le cache se met à jour toutes les 24 heures. Cet intervalle peut être modifié en définissant la propriété squash.bugtracker.cache-update-delay dans le fichier squash.tm.cfg.properties.

Configure the GitLab cache