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 plugins correspondant à 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 icone ajouter ou de supprimer icone suppression 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.

Popup 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 pour le créer (4).
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". Quelque 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 inclus la configuration de protocole, les identifiants applications de Squash et les jetons OAuth des utilisateurs le cas échéant. Les login/mot de passe personnels des utilisateurs (Basic Authentication) sont sauvegardés encryptés dans la base de données.