Update functions to use RestURL base path from Get-JiraConfigServer instead of $issue.RestURL

[Adam-Wenger]

Our company's installation of Jira requires me to use JiraPS pointed at the computer name of our Jira server instead of the website address of our Jira application. For us, access denied errors are encountered when we try to go against the website path.

I was provided a workaround on the slack page to do the following:

$jiraIssue = Get-JiraIssue -Issue $issue;

$internalBase = Get-JiraConfigServer; # https://computername.cn2.domain.internal.other.com
$externalBase = $jiraWebsite;         # https://jira.domain.internal.other.com
$jiraIssue.RestURL = $jiraIssue.RestURL -replace $externalBase, $internalBase;

$jiraIssue | Set-JiraIssue @setIssueParams;

This works, but means that I must pipe in all issues, and all of our code that gets a $jiraIssue must update/fix the $jiraIssue.RestURL value before we can use it. There are also some locations that this appears to not work (Getting an attachment)

If function calls were to grab the base URL path from Get-JiraConfigServer instead of the $Issue specific RestURL parameter, this workaround would no longer be necessary. It would also help future users who have similar security issues with their installations.

It could also be added as an optional setting if there were concerns of breaking backward compatibility for existing users.

[lipkau]

Hi @Adam-Wenger

I am sorry you are facing this problem. unfortunately, not only do I not agree with this change; but I plan on moving a lot more logic into using them restURL property. I will investigate with Atlassian about this. but I would be surprised to hear that it is recommended to use "hardcoded" baseurl instead of leveraging the self property of the objects. when you have multiple jira servers linked between them, I would argue that self or (restURL) is far more reliable than using the base url.

I do however have a suggestion for your code: extract the logic into a function that accepts pipeline. Could look something like this:

#region mock
    Set-JiraConfigServer "https://powershell.atlassian.net"
    $script:jiraWebsite = "https://not.a.real.url"
#endregion mock

#region functions
    function Fix-IssueURL {
        [CmdletBinding()]
        param (
            [Parameter(Mandatory, ValueFromPipeline)]
            [PSCustomObject]
            [PSTypeName('JiraPS.Issue')]
            $Issue
        )

        process {
            foreach ($_issue in $Issue) {
                #real code:
                # $_issue.RestURL = $_issue.RestURL -replace $script:jiraWebsite, (Get-JiraConfigServer)
                #fake code for demo:
                $_issue.RestURL = $_issue.RestURL -replace (Get-JiraConfigServer), $script:jiraWebsite

                $_issue
            }
        }
    }
#endregion functions

#region execution
    $jiraIssue = Get-JiraIssue -Issue TV-14
    "before: $($jiraIssue.RestURL)"
    $jiraIssue = $jiraIssue | Fix-IssueURL
    "after: $($jiraIssue.RestURL)"

    # real use case:
    # Get-JiraIssue -Issue TV-14 | Fix-IssueURL | Set-JiraIssue @setIssueParams
#endregion execution

which outputs the following:

[Adam-Wenger]

Thanks for the quick response @lipkau - I'll keep chasing the folks here who did the installation to try to sort out the permissions issues here for the real fix, and continue with the options you've provided in the mean time. Cheers.

[Adam-Wenger]

Our CI/CD team suggested a hosts file entry that helps resolve the permissions issue in most situations for me.