Add support for Approvals

[jrwarwick]

Context

Examining the outstanding approvals on JIRA ServiceDesk issues is helpful in preventing stalling of progress on issues. Especially since there is not out of the box way to re-send approval requests. This could help with sending reminders to users who are the named approvers, but have missed or forgotten the notification.

Description

Implement a new cmdlet, perhaps named Get-JiraIssueApprovals that behaves a bit like existing cmdlet: Get-JiraIssueWatcher [-Issue]

[lipkau]

Hi @jrwarwick

Unfortunately, Service Desk is not part of JiraPS.

In order to support Jira Service Desk, we would need to create a new module (probably called JiraServiceDeskPS). The reason is, the APIs are very different and they are actually different products.

But here is a basic implementation you can use (or write a module yourself) for the approvals:

function Get-JiraIssueApproval {
    [CmdletBinding()]
    param(
        [Parameter( Mandatory, ValueFromPipeline, ValueFromPipelineByPropertyName )]
        [Alias('Key')]
        [String]
        $IssueKey,

        [Parameter()]
        [System.Management.Automation.PSCredential]
        [System.Management.Automation.Credential()]
        $Credential = [System.Management.Automation.PSCredential]::Empty
    )

    begin {
        $server = Get-JiraConfigServer
    }
    process {
        ConvertFrom-Json (Invoke-JiraMethod -URI "$server/rest/request/$IssueKey/approval" -Credential $Credential).Content
    }
}

[jrwarwick]

Thanks for the explanation, @lipkau , moreover for the sample code. To top off your list of reasons it does not fit in with JiraPS, it seems that the API in ServiceDesk is still even considered partially experimental! Anyway, I took what you started with here and found a few tweaks necessary to get it to run against our server/on-prem install of JIRA, and even then the convertFrom-json call still had some trouble with it, so I just grabbed the values property and sent it back:

function Get-JiraIssueApproval {
    [CmdletBinding()]
    param(
        [Parameter( Mandatory, ValueFromPipeline, ValueFromPipelineByPropertyName )]
        [Alias('Key')]
        [String]
        $IssueKey,

        [Parameter()]
        [System.Management.Automation.PSCredential]
        [System.Management.Automation.Credential()]
        $Credential = $global:jiraCredential ##[System.Management.Automation.PSCredential]::Empty
    )

    begin {
        $server = Get-JiraConfigServer
    }
    process {        
        #chokes on null input or invalid primitive or something
        #ConvertFrom-Json (Invoke-JiraMethod -URI "$server/rest/servicedeskapi/request/$IssueKey/approval" -Headers @{'X-ExperimentalApi'='opt-in'} -Credential $Credential).Content
        $(Invoke-JiraMethod -URI "$server/rest/servicedeskapi/request/$IssueKey/approval" -Headers @{'X-ExperimentalApi'='opt-in'} -Credential $Credential).values
    }
}

It will still be very useful, I think. I do hope to one day see such a module as "JiraServiceDeskPS". I know our company would use it. Thanks again.

[lipkau]

Invoke-JiraMethod already runs ConvertFrom-Json internally. my mistake

/rest/servicedeskapi/request is that custom? didn't see that in the docs

-Headers @{'X-ExperimentalApi'='opt-in'} #mindblown

I do hope to one day see such a module as "JiraServiceDeskPS"

I can set up the module right now. But I don't have time to write it myself. (nor the server setup)

[jrwarwick]

If I understand your question, then, no, not custom:

https://docs.atlassian.com/jira-servicedesk/REST/3.9.1/#servicedeskapi/request

https://docs.atlassian.com/jira-servicedesk/REST/4.5.0/?_ga=2.170039781.491384647.1572993029-715180182.1572541917#servicedeskapi/request/{issueIdOrKey}/approval

Even though service desk is a different product, it is of a kind that would almost be better described as "extension". It requires a complete, working jira instance to install into. I don't know how that best translates into PS structures, but I successfully used JiraPS "out of the box" and just built one or two little extra cmdlets, much like above.

[lipkau]

If I understand your question, then, no, not custom:

https://docs.atlassian.com/jira-servicedesk/REST/3.9.1/#servicedeskapi/request https://docs.atlassian.com/jira-servicedesk/REST/4.5.0/?_ga=2.170039781.491384647.1572993029-715180182.1572541917#servicedeskapi/request/{issueIdOrKey}/approval

You are right. My mistake.

Even though service desk is a different product, it is of a kind that would almost be better described as "extension". It requires a complete, working jira instance to install into. I don't know how that best translates into PS structures, but I successfully used JiraPS "out of the box" and just built one or two little extra cmdlets, much like above.

The same argument would apply to every Jira plugin. This plugin for example: Xporter - Export issues from Jira. It has an API. Just as ServiceDesk, the API is in a different namespace as Jira Core, it is versioned differently, it requires different headers. One can hope that the authentication is the same - I have already seen plugins where it is not. The same applies to Jira Agile (api): it is shipped with Jira Core, but the API is still kept separate.

Therefore, as long as the API is not in the document as the API from Jira Core, I will insist for it to be a separate module. You can see the conversation about Jira Agile here: https://github.com/AtlassianPS/JiraPS/pull/383

[jrwarwick]

Thanks for helping understand. I think it would definitely be worthwhile to take the same approach as demonstrated in #383 for Jira Agile. In fact, it looks like sgtwilko has already done so much solid work, the new module could almost start out as a copy JiraAgilePS and just modify.