Atlassian JIRA

Technical requirements

SD Elements supports integration with JIRA Server (until Feb 15, 2024), JIRA Cloud & JIRA Data Centre.

The following requirements must be met to integrate JIRA with SD Elements.

  • Server version must be 8.x, or 9.x.

  • Server configuration must enable remote API access.

    • The option "Accept remote API calls" must be set to "ON".

    • For more information, see the online documentation.

  • Basic authentication must be enabled for connection users.

  • The user configured for the connection should:

    • Be a member of the project

    • For Countermeasure syncs, users should have permission to create, tag, transition, and resolve issues.

      • Specific permissions: CREATE_ISSUES, CLOSE_ISSUE, ASSIGN_ISSUES, TRANSITION_ISSUES, RESOLVE_ISSUES

    • For comment syncs, users should have permission to add and edit comments, as well as administer projects for checking if a project is public or not.

      • Specific permissions: CREATE_COMMENTS, EDIT_ALL_COMMENTS, ADMINISTER_PROJECTS

Default assigned fields

The following fields are set by default:

  • Summary

  • Description

  • Labels

  • Priority

Behavior

The integration supports the following:

Default Priority Mapping

SD Elements

Jira

10

Blocker

7-9

Critical

5-6

Major

3-4

Minor

1-2

Trivial

Connection details

Enter the connection details for the server.

Protocol

Select the protocol for the connection (HTTPS or HTTP) (Default: HTTPS)

Server

The domain name or IP address of the server (Example: jira.server.com)

Context Root

Top-level location where JIRA is installed on a server. The value for this may be dependent on the configuration of an internal corporate proxy or where an administrator has installed JIRA.

Credentials

Enter the credentials needed to authenticate to the server.

Authentication Method

Specifies the authentication method used when communicating with JIRA. There are two choices: Basic, and Personal Access Token.

Username

This configuration is available if the user selects Basic for the Authentication Method. Username authorized to connect with the server. This user should be able to create and edit stories/issues in JIRA.

Password/API Token

This configuration is available if the user selects Basic for the Authentication Method. This is the specified user’s password or API token used to authenticate to the server. Note: Jira deprecated password authentication for its Jira Cloud API endpoints in June 2019.

Personal Access Token

This configuration is available if the user selects Personal Access Token for the Authentication Method. This is the Personal Access Token of a user used to authenticate to the server. This user should be able to create and edit stories/issues in JIRA.

Countermeasures to Synchronize

Select Countermeasures to synchronize.

Sync all Countermeasures

Synchronize all Countermeasures from SD Elements.

Sync Risk Policy Countermeasures

Synchronize only Countermeasures that fall under the risk policy.

Project details

Enter the project-level details.

JIRA Project Key

The key for the project where issues should be created.

Advanced JIRA configuration

Enter advanced configuration options.

Issue Type

Type of work item that SD Elements will create when creating a Countermeasure in JIRA. (Default: Bug)

Map a JIRA status to an SD Elements status

This mapping determines the status to assign an SD Elements Countermeasure based on its corresponding JIRA issue status.

Any unmapped JIRA status is mapped to the 'Incomplete' SD Elements status.

Optional: Adding a Jira Resolution field as an additional mapping parameter under Jira statuses. For example, (Done, Won’t Fix) = 'Not Applicable'.

The Jira Resolution field only supports the system field, not any custom fields named Resolution.

See Status Mapping for more information.

Map an SD Elements status to a JIRA status

This mapping determines the status to assign a JIRA issue based on its corresponding SD Elements Countermeasure status. All JIRA statuses in this mapping should be a single transition away from every other status in the mapping, as well as from the default status for new issues in your JIRA project workflow.

'Incomplete', 'Complete', and 'Not Applicable' SD Elements statuses must have a mapping. Any unmapped custom SD Elements statuses will use these mappings based on their meaning.

Optional: Adding a Jira Resolution field as an additional mapping parameter under Jira statuses. For example, (Done, Won’t Fix) = 'Not Applicable'.

The Jira Resolution field only supports the system field, not any custom fields named Resolution.

See Status Mapping for more information.

Closed Issue Status

The name of a status in JIRA to use when its corresponding SD Elements Countermeasure is removed from the project. Option to add Jira Resolution field as an additional mapping parameter with the Jira Status (Done, Won’t Fix)

Synchronization

Enter settings for synchronizing the SD Elements and JIRA projects.

Skip & Log Error

Select this option if you would prefer to let the sync run fully, providing you with total errors found at the end of each sync process.

Authoritative Source

Select the tool that will be the authoritative system of record: JIRA or SD Elements. This field is used in case of conflicting statuses between the JIRA issue and the SD Elements Countermeasure. When you first synchronize a TODO Countermeasure in SD Elements with an issue in JIRA, they will have the same status. If you then change the status in one tool, for example by closing the issue in JIRA, they will have conflicting statuses. This conflict is resolved when the projects are synchronized. There are three options:

  • Issue Tracker (default): The SD Elements Countermeasure will be updated to match the status in JIRA. This is relevant to most workflows.

  • SD Elements: The JIRA status will be updated to match the SD Elements status.

  • Last Updated: The SD Elements and JIRA states will always reflect the latest update status. For example, if a JIRA issue is most recently updated then the SD Elements Countermeasure status will be updated to reflect the JIRA status. The opposite is also true.

Include code sample How-To’s in Countermeasure descriptions

Whether or not to include detailed code samples and How-To’s in the JIRA issue.

Include comments/notes

Select this option to enable comments/notes between SD Elements and Jira (currently only from SD Elements to Jira). This will synchronize notes in real-time for both automatic or manual notes.

Before notes can be synced you will need to conduct an initial project sync and ensure that the Countermeasures have been created as tasks in JIRA. Any comments/notes added before an initial sync will not be back-ported.
This option is not supported if SD Elements is using the Remote Integration Agent to connect to Jira.

This Issue Tracker server is hosted within a private network and cannot be reached directly by SD Elements.

Select this option if SD Elements does not have direct network access to the JIRA server.

For example, if you are using a hosted SD Elements instance but you want to integrate with an internal/protected JIRA system, choose this option and run the Remote Integration Agent to perform integration.

Filter Countermeasures

Select SD Elements Countermeasures that are synchronized with the JIRA project.

Countermeasures having a minimum priority

Synchronize Countermeasures with a minimum priority (for example, 7 or above). This is useful if you want to limit the amount of work for users. (Default: 1)

Countermeasures with status meaning

Synchronize only Countermeasures with certain statuses, such as TODO or DONE. (Default: TODO)

Limit to Countermeasures having these phases

Synchronize only Countermeasures in certain phases, such as Requirements or Development. (Default: none selected, meaning Countermeasures from all phases will be synchronized)

Countermeasures having all of the following tags

Synchronize only Countermeasures containing certain SD Elements Countermeasure tags. (Optional)

Countermeasures with verification status

Synchronize only Countermeasures with a specific verification status, such as Pass or Fail. (Default: none selected, meaning Countermeasures with any verification status will be synchronized)

Advanced Issue Tracker options

Enter advanced configuration options.

Issue Tracker Title Format

Issues created in JIRA will be given titles that match this format. (Default: "T21: Countermeasure Title")

Bypass server certificate validation for HTTPS (insecure, only for testing purposes)

Check this option if you need to test a connection without the proper SSL/TLS certificates.

Issue Labels / Tags

Tag value assigned to JIRA issues (Default: SD-Elements)

Issue Tracker parent issue

JIRA project issue to use as the parent issue. SD Elements Countermeasures will be created as children of the parent issue. This is only applicable when creating issue types that are of type "Sub-Type" or similar.

Custom Priority Mapping

If the standard JIRA priorities have been customized, you must map the customized priority names in JIRA to their corresponding SD Elements numeric priorities.

This is a common option that will need to be set.

For example, map "Blocker" issues to priority 10 in SD Elements, "Critical" to priorities 7-9, and so on.

Custom Fields Mapping

In addition to the default-assigned fields, you can map additional JIRA fields or override the values for the default-assigned JIRA fields.

Fields that are not required or have default values do not need to be set.

For example, you may have a required field in your JIRA project that is not set by default. Custom field mappings can be set at both the system connection and project connection levels, and that mappings set in a project connection will override mappings set in the system connection.

The exact name of the JIRA field is required for the mapping to succeed. This may be subject to locale differences for your service user and JIRA instance. Date-type JIRA fields are supported but the value must be in the format expected by JIRA. By default dates must be in the form yyyy-MM-dd. Contact your JIRA administrator if a different format is expected.

Only on INITIAL sync would these fields be populated and no further updates can be made if customized after the sync has occurred.

For more details refer to section Advanced field support.

Custom Lookup Fields

Deprecated method to sync more than one SD Elements project to a JIRA project. As of release 4.1, integrations that use Custom Lookup Fields will automatically be converted to the new method upon their next run.

Issue Tracker context

Provide a specific identifier to this project integration that can be used in an issue’s generated title format. This is applicable only when option Issue Tracker Title Format contains "Context"

Sync frequency

Select how frequently the SD Elements and JIRA projects are synchronized. You can choose from the following options. The more frequently you run synchronization, the greater the performance impact on both the SD Elements and JIRA servers. This is generally only a concern for large organizations running many synchronizations at once.

Hourly, Daily, Weekly, or Monthly

The projects will synchronize automatically every hour, day, week or month. Daily synchronization is typically sufficient, however you may want to select a more frequent interval if development moves quickly in your organization.

Manually

You must click the Sync button on the Issue Tracker Integrations page to synchronize the projects. This is the default value.

results matching ""

    No results matching ""