Differences

This shows you the differences between two versions of the page.

--- jira_addon [2016/09/22 02:35] – external edit 127.0.0.1
+++ jira_addon [2020/05/10 16:13] (current) – removed admin
@@ Line 1: / Line 1: @@
-===== JIRA AddOn Configuration =====
-//JIRA Addon// communicates with {{https://www.atlassian.com/software/jira | JIRA}} using REST API.  To configure //JIRA AddOn//, you need to provide the JIRA server connection information at the minimum, e.g.:
-    ADDON.myjira.CLASS=com.webmbt.plugin.alm.jira.AddOnJira
-    ADDON.myjira.CONNURL=<url>
-    ADDON.myjira.PASSWORD=<pwd>
-    ADDON.myjira.USERNAME=<user>
-    ADDON.myjira.REQ.ENABLED=true
-    ADDON.myjira.BUG.ENABLED=true
-where ''myjira'' is a unique name you assign to identify the integration.
-The above example defines ''myjira'' to server as the requirement and defect system.  You can split requirement from defect into its own system as well by configuring them with their own unique names.
-  * ADDON.myjira.REQ_ID: Requirement/User Story tag (requirement identifier, or reqtag)
-  * ADDON.myjira.STORY_ID: Requirement Associated User Story tag. Applicable specifically for requirements, it is expected that when referencing a user story directly, finding the User Story tag will be referencing the same field ID as identified by REQ_ID.
-  * ADDON.myjira.REQ_STATUS: Requirement Status field (for requirement type issues)
-  * ADDON.myjira.STY_STATUS: User Story Status field (for user story issues)
-  * ADDON.myjira.REQ_PRIORITY: Requirement/User Story Priority
-  * ADDON.myjira.MODEL_NAME: For defects, the model that submitted the defect
-  * ADDON.myjira.MODEL_VERSION: For defects, the model version when the defect was created.
-  * ADDON.myjira.SOURCE=JAMA|POLARION|JIRA, default to JIRA
-  * ADDON.myjira.TAGTYPE=r|s|e|r,e,s. TAGTYPE defines whether the Req Tags that we assert against are recorded as JIRA requirement issues (r), enhancements (e) and / or JIRA User Story issues (s). The definition of both in TAGTYPE means that the Req Tag could be either a requirement, enhancement or User Story issue.
-These fields can be elected to be overriden in the config.properties, or the model's ALM configuration.
-JIRA AddOn requires field mappings. You may customize the field mappings as described below. If not specified, default values will be used:
-For the Defect Issues, we create two custom fields:
-  * Test Version: which holds the model version from the TestOptimal model
-  * Test Identifier: which holds the model name from TestOptimal.
-Within the custom field control panel within JIRA, you define which issue types are relevant for each custom field.
-For bugs / defects, there are two mandatory custom fields that default to the following values:
-  * Model name (that raised the defect): Test Identifier  (must be defined as readonly text field or other text field. default jira defined this to be Labels which does not work.
-  * Model version: Test Version  (same as Test Identifier)
-=== Use JIRA AddOn in Model ===
-Each model that needs to access JIRA for requirement or defects must also be configured:
-  * Enable[[ALMPlugin]] in the model using [[modelnode | model property]].
-  * Select 'myjira' as the requirement and/or defect system using [[alm_configuration | ALM Configuration]].
-Additional configuration is needed to complete the JIRA AddOn for the model. You need to tell JIRA which project to access and some further customization like how you would like requirements to be linked, etc.
-  * PROJECT=<project key>, this is one tag that would be expected to always be defined in the model's ALM configuration (once for Req and once for Bug), as each model would be expected to relate to a specific project. It tells the ALM plugin which project to search/lodge requirements and defects against.