This code extracts data from Jira based on a yaml config file, and outputs a properly formatted CSV that can be read by the ActionableAgile Analytics tool.
Suggested changes to pull "name" instead of value for some custom fields and added logic to pull resolution date if (Resolved) in last workflow stage #13
Custom field 2 has the following JSON structure:
"customfield_15713": {
"self": "https://jira2.company.com/rest/api/2/version/63728",
"id": "63728",
"name": "XY 2492",
"archived": false,
"released": false,
"releaseDate": "2015-12-10"
}
The logic for custom fields only pulled the structure with "value" (Custom field 1) and not with "name" (Custom field 2)
So, I added logic to check if the “value” element is empty, then pull the “name” element.
Second, I found out that if you put (Created) in the first Section of the workflow, it will pull in the Created date (essentially, the submitted date) of the JIRA. Well, we had a limitation for this in that when we migrated issues from another system db to JIRA, it did not migrate status changes (transitions). So, all we had for the majority of those issues was the created date and the resolved date. I added some logic that if you add (Resolved) to the last Section of the workflow, it will pick up the resolution date if it exists for the JIRA issue being imported. This is very specific to the “Closed” status and will pull in issues that don’t have a status change to closed. Essentially, it just goes after the migrated issues to provide some history.
I have changes in 2 files for 2 issues that I was trying to address.
First, not all custom fields are configured the same way. Here are JSON examples of the two versions of custom fields
Custom field 1 has the following JSON structure: "customfield_10011": { "self": "https://jira.company.com/rest/api/2/customFieldOption/10011", "value": "No", "id": "10011" }
Custom field 2 has the following JSON structure: "customfield_15713": { "self": "https://jira2.company.com/rest/api/2/version/63728", "id": "63728", "name": "XY 2492", "archived": false, "released": false, "releaseDate": "2015-12-10" }
The logic for custom fields only pulled the structure with "value" (Custom field 1) and not with "name" (Custom field 2) So, I added logic to check if the “value” element is empty, then pull the “name” element.
Second, I found out that if you put (Created) in the first Section of the workflow, it will pull in the Created date (essentially, the submitted date) of the JIRA. Well, we had a limitation for this in that when we migrated issues from another system db to JIRA, it did not migrate status changes (transitions). So, all we had for the majority of those issues was the created date and the resolved date. I added some logic that if you add (Resolved) to the last Section of the workflow, it will pick up the resolution date if it exists for the JIRA issue being imported. This is very specific to the “Closed” status and will pull in issues that don’t have a status change to closed. Essentially, it just goes after the migrated issues to provide some history.