Skip to content

Manage Bugtrackers and Synchronization Servers

Bugtrackers vs Synchronization Servers

In Squash TM, there are bugtracking plugins and synchronization plugins, which both differ from one another.
Bugtracking plugins are used to report issues from Squash TM to third-party tools such as bugtrackers.
Synchronization plugins are used to synchronize issues from third-party tools dedicated to IT project tracking to Squash TM.

Here is the list of third-party tools that can be interfaced with Squash TM:

Plugin Name Category Type in the Servers workspace Third-party Tools
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 Synchronization jira.xsquash Jira Server, Jira Data Center, Jira Cloud
Jira Automation Workflow Synchronization jira.rest ou jira.cloud Jira Server, Jira Data Center, Jira Cloud
Redmine Bugtracker Bugtracking redmine3.rest Redmine
Redmine Requirements Synchronization redmine3.rest Redmine
Azure DevOps Bugtracker Bugtracking azuredevops.bugtracker Azure DevOps
RTC Bugtracker Bugtracking rtc Rational Team Concert
Tuleap Bugtracker Bugtracking tuleap Tuleap

Learn More

You have to install the plugin(s) corresponding to the tool you want to use to access these bugtracking and/or synchronization features.
To learn more about these plugins, please visit these pages: Squash TM Plugins, Install Squash TM Plugins.

Add, Modify, and Delete a Bugtracker and a Synchronization Server

You can manage bugtrackers and synchronization servers from the Administration workspace, in "Servers" submenu, via the Bugtrackers and synchronization servers anchor Bugtrackers and synchronization servers.

From the Manage bugtrackers and synchronization servers table, you can add add icon or delete delete icon one or multiple servers. You can also delete a bugtracker or synchronization server from their consultation page by clicking on the button [...].

Table - Manage bugtrackers and synchronization servers

When you create a bugtracker or synchronization server, you must enter its name (unrestricted), choose the type of server it is in the drop-down list, and enter the URL of the third-party tool. The URL must be as short as possible because it is used as a base for every API request used by Squash TM to communicate with the third-party tool. All these fields are mandatory.

Popup - Create BT or synchronization server

By clicking on its row number (#) or name, the server's consultation page appears, so you can modify it. The anchor bar enables you to navigate between the different blocks.

BT or synchronization server consultation page

Warning

When you delete a bugtracking server, it is automatically deleted from the project with which it was associated. The value "Bugtracker step" appears on the project's consultation page.
All the associations with issues in the "Known Issues" blocks are also deleted.

Configure a Bugtracker or Synchronization Server

To get a bugtracker to accept to exchange information with Squash TM, you must identify Squash TM. By managing authentications, you can decide how users, or Squash TM will authenticate themselves on the server. The Manage authentications page has two blocks:

  • The "Authentication protocol" block that defines the security protocol used to authentify the connection;
  • The "Authentication policy" that determines how users and/or Squash TM authenticate themselves.

Authentication Protocol

The "Authentication protocol" block enables you to define the authentication protocol. The protocols supported by Squash TM are Basic Authentication, 0Auth 1a (only for Jira connectors), and Token Authentication (only for GitLab and Mantis connectors). The protocols suggested during the configuration depend on your type of bugtracker.

Focus

When you change the authentication protocol, the change immediately applies. The previous configuration becomes obsolete and is deleted from the server. However, the information remains on the page as long as the page isn't closed or refreshed: if the protocol is accidentally modified, you can restore the previous protocol and save the configuration again.

Basic Authentication

Basic Authentication is the default protocol. The authentication is based on the user's login and password input. It is supported by all servers except GitLab and Mantis. It does not require any additional configuration. Using Basic Authentication is only secured when it is used with SSL/TLS (https).

Jira Cloud

To connect to Jira Cloud, you need an API Token instead of a usual password, although the Basic Authentication protocol is used.
Regardless of the chosen authentication policy, in the "Login" field, enter your user email, and in the "Password" field, enter the API token generated for the account on Jira Cloud.
The procedure to generate a personal API token is detailed on this page: Create and API token.

Azure DevOps

Azure DevOps needs an API Token instead of a password to authenticate, although the Basic Authentication protocol is used.
Regardless of the chosen authentication policy, in the "Login" field, enter your Azure DevOps organization name, and in the "Password" field, enter the personal API token generated for the user on Azure DevOps. "Read & Write" clearances on Work Items are enough.
The procedure to generate a personal API token is detailed on this page: Use personal access tokens to authenticate.

OAuth 1a

As of now, this protocol is only used by Jira connectors. To use it, you must configure the URLs involved in token exchanges and methods for signing requests. You must complete the token and token secret fields in the "Authentication policy" block.

Learn More

To learn more about how to configure the 0Auth 1a protocol, please read this part Configure the 0Auth 1a Authentication Protocol.

Token Authentication

As of now, this protocol is only used by GitLab and Mantis. This authentication is based on the user entering a token in a third-party tool, and does not require any further configuration.

GitLab

To generate a token on GitLab, please visit the page Personal access tokens.

Mantis

To generate a Mantis API token, go to "My account" (1), then "API Tokens" tab (2).

Generate a Mantis API token

Enter an explicit token name in order to revoke it if needed (3), then click on the button to create it (4).
Copy the generated token and paste it in the apropriate Squash field, depending on the chosen authentication policy.

Authentication Policy

The "Authentication policy" block enables you to choose how users can authenticate on the bugtracker or synchronization server.

Server/BT Authentication Policy

  • Users authenticate themselves: Every user must authenticate themselves to the third-party tool. The login procedure varies depending on the chosen protocol. For a Basic Authentication, the user must enter their login and password to connect to the third-party tool in Squash TM. For 0Auth 1a, they must authenticate themselves directly in the third-party tool in a separate window.

  • Use Squash TM credentials: users no longer need to authenticate themselves. The server automatically uses the third-party credentials entered in the field "Squash TM credentials". No matter the user logged into Squash TM, the data is transmitted to the third-party tool thanks to the user credentials entered in that block.

Info

We recommend the option "Users authenticate themselves" to configure bugtrackers. Thus, the username is entered as the issue reporter, instead of a common user. This enables you to trace the exchanges between Squash TM and the third-party tool.
You should use the option "Use Squash TM credentials" when configuring a synchronization server, especially for Xsquash4Jira when synchronizing with a technical account, Xsquash4Jira and the Jira Automation Workflow plugin.

You only have to complete the "Squash TM credentials" field when the option "Use Squash TM credentials" is checked.

For the fields to be successfully saved:

  • The third-party tool must be reachable;
  • The credentials to connect to the third-party tool must be the right ones;
  • The account associated with these credentials must have the necessary permissions in the third-party tool;
  • The configuration of the server must be done correctly.

Info

Squash TM keeps some information regarding authentication in its database. This information includes the protocol configuration, the Squash TM app credentials, and the 0Auth user tokens if need be. Users personal logins/passwords (Basic Authentication) are encrypted and saved in the database.