Use relative links for objects within the same Confluence instance

[monti-python]

Solves #456

[st-karol]

Looks good from my perspective 👍

[mrueg]

Won't this always provide the relative path instead of the absolute path with baseurl now?

I think it would be good to have tests for this one, I'd like to avoid breaking things again. Would you be willing to write some?

[monti-python]

Hi @mrueg,

Thanks a lot for reviewing!

Indeed, relative paths should always work. The problem last time was that, in the case of Confluence Cloud, baseURL already contains a subpath (/wiki) that should be prepended to those relative paths (Scenario 2 below).

In this case we take a more robust approach by forming the absolute URL first, then returning the relative path to make the page links independent of the hostname.

Scenario 1 - baseURL doesn't contain a subpath (Confluence Server)

• baseURL: https://[my_server_hostname]>
• pageLink: /spaces/~spaceId/my_page
• absoluteURL: https://[my_server_hostname]>/spaces/~spaceId/my_page
• relativePath: /spaces/~spaceId/my_page (equal to pageLink)

Scenario 2 - baseURL contains a subpath (Confluence Cloud)

• baseURL: https://[company-name].atlassian.net/wiki
• pageLink: /spaces/~spaceId/my_page
• absoluteURL: https://[company-name].atlassian.net/wiki/spaces/~spaceId/my_page
• relativePath: /wiki/spaces/~spaceId/my_page ("/wiki" + pageLink)

I thought about adding a separate function to isolate and test this functionality:

func getRelativePath(absoluteLink string) (string, error) {
	linkUrl, err := url.Parse(absoluteLink)
	if err != nil {
		return "", karma.Format(err, "parse URL: %s", link)
	}
	return linkUrl.Path, nil
}

However, testing this function would be equivalent to testing the url library (linkUrl.Path).

In any case, I'm happy to write those tests if you think they'd provide any value.

[mrueg]

Thanks for the further explanation. I think this looks good now. I got confused because I initially thought we'll only replace links in cloud. :)