Modified ConvertTo-JiraProject to store the 'style' value returned from project REST API so a given project can be differentiated between next-gen or classic.
Modified New-JiraIssue (and similarly to Get-JiraIssueCreateMetadata) to avoid use of Get-JiraIssueType - all the data that required this cmdlet to be called is already stored in $projectObj. Additionally, Get-JiraIssueType does not support mixed environments with classic and next-gen projects. The original errors we got were a result of Get-JiraIssueType returning multiple IDs for a given Issue Type name.
New-JiraIssue also had an issue with the "reporter" field being unset on a next-gen project. Classic projects seems to automatically set the reporter field to the current user if not set, but next-gen projects do not seem to behave the same, so I modified New-JiraIssue to force setting the reporter field if the target project is flagged 'next-gen' from the style field.
Finally, added some more helpful error handling in both New-JiraIssue and Get-JiraIssueCreateMetadata - previously an unhelpful error message was presented to the user if the selected Issue Type was not valid for the input Project, after this fix the error returned to the user is explicit about the input Issue Type being invalid for the Project.
Unit tests for the two Public functions needed to be updated to provide the requisite IssueTypes data on the Mock Get-JiraProject stubs.
Motivation and Context
With current develop branch, New-JiraIssue presents an error in our staging and development Jira instances:
New-JiraIssue -Project "TP1" -IssueType "Task" -Summary "Test test 123" -Priority 1 -Description "Test test 321"
Get-Member : You must specify an object for the Get-Member cmdlet.
At C:\shareDocs\Programming\JiraPS\JiraPS\Private\ConvertTo-JiraCreateMetaField.ps1:14 char:28
Description
Modified ConvertTo-JiraProject to store the 'style' value returned from project REST API so a given project can be differentiated between next-gen or classic.
Modified New-JiraIssue (and similarly to Get-JiraIssueCreateMetadata) to avoid use of Get-JiraIssueType - all the data that required this cmdlet to be called is already stored in $projectObj. Additionally, Get-JiraIssueType does not support mixed environments with classic and next-gen projects. The original errors we got were a result of Get-JiraIssueType returning multiple IDs for a given Issue Type name.
New-JiraIssue also had an issue with the "reporter" field being unset on a next-gen project. Classic projects seems to automatically set the reporter field to the current user if not set, but next-gen projects do not seem to behave the same, so I modified New-JiraIssue to force setting the reporter field if the target project is flagged 'next-gen' from the style field.
Finally, added some more helpful error handling in both New-JiraIssue and Get-JiraIssueCreateMetadata - previously an unhelpful error message was presented to the user if the selected Issue Type was not valid for the input Project, after this fix the error returned to the user is explicit about the input Issue Type being invalid for the Project.
Unit tests for the two Public functions needed to be updated to provide the requisite IssueTypes data on the Mock Get-JiraProject stubs.
Motivation and Context
With current develop branch, New-JiraIssue presents an error in our staging and development Jira instances:
New-JiraIssue -Project "TP1" -IssueType "Task" -Summary "Test test 123" -Priority 1 -Description "Test test 321" Get-Member : You must specify an object for the Get-Member cmdlet. At C:\shareDocs\Programming\JiraPS\JiraPS\Private\ConvertTo-JiraCreateMetaField.ps1:14 char:28
Types of changes
Checklist