How to retrieve the actual Jira instance I am in?

Perhaps it is the easiest thing to do but I stumbled into this. Looked inside context, issue data, UI Kit hooks, Javascript API and came empty-handed.

I can get some Ids but I really need the domain like https://myinstance.atlassian.net there.

Maybe there is a way to access the current URL?

1 Like

Hello @RichardVencu.

You can get the instance URL from the context using “xdm_e” as stated in Context guide - Context parameters (atlassian.com) .

Also, you can get the URL/URI from the HTTP request itself inside the controller of the framework you use (e.g. Connect for Express or Connect for Spring ) and pass it to the UI model of the templating language you use.

Hope this can help you.

This is a forge app, I don’t think the xdm_e query string parameter is available given that it does not run in an iframe (like Connect)

We asked about this in the decommissioned Forge Slack channel and got advise from the Forge team how to deduce the site information, though it turned out to be only applicable for Jira and not Confluence at the time (right now you can still apply the Jira approach on Confluence because Forge is not enabled for Confluence only sites).

Unfortunately I’ve misplaced my notes and cannot recall the details right now :man_facepalming: - will reply once more in case I find/recall those.

I do recall our workaround though, which is based on Tim Pettersen’s clever answer to Status URL for monitoring?:

There isn’t a formal status API that I’m aware of, but the AppLinks Manifest end-point is a good URL you can hit for most of our products (JIRA, Confluence, Stash, Bamboo, FishEye and Crucible). If it returns a 200, your server is probably in good shape.

It does not require authentication and is available at:

/rest/applinks/latest/manifest

in all products.

e.g.

https://jira.atlassian.com/rest/applinks/latest/manifest

https://confluence.atlassian.com/rest/applinks/latest/manifest

cheers,

Tim

This still seems to work fine on Atlassian Cloud, though you need to parse the response XML, see e.g.:

Jira
https://utoolity.atlassian.net/rest/applinks/latest/manifest

...
<name>Jira - Utoolity Support</name>
...
<url>https://utoolity.atlassian.net</url>
...

Confluence
https://utoolity.atlassian.net/wiki/rest/applinks/latest/manifest

...
<name>Confluence - Utoolity Support</name>
...
<url>https://utoolity.atlassian.net/wiki</url>
...
2 Likes

Great! Thank you, this works well:

getInstance = async () => {
    const response = await api
      .requestJira(`/rest/applinks/latest/manifest`);
    const results = await response.text();
    const jurl = /\<url\>(.*)\<\/url\>/;
    return jurl.exec(results)[1];
  }
1 Like

I can jump in on that - the Jira only, slightly more explicit approach uses the baseUrl entry from /rest/api/3/serverInfo, e.g.:

export const getEnvironmentBaseUrl = async () => {
  let result;
  // NOTE/KLUDGE: We have no proper approach for Confluence so far, but can currently rely on a Confluence instance always having a
  // corresponding Jira instance, hence using the respective Jira pproach only for starters:
  //const hostProduct = getHostProduct();
  const hostProduct = "jira";
  if (hostProduct === "jira") {
    result = await api
      .asApp()
      .requestJira("/rest/api/3/serverInfo");
    const serverInfo = await result.json();
    result = serverInfo.baseUrl;
  }
  // TODO: Add Confluence specific version, once available
  return result;
}

(left the preparation and notes on the Confluence topic, easy to shorten for a Jira only situation, of course)

3 Likes

Hey @RichardVencu,

Would you mind describing a little about what you need this for? That way I can take it back to my team. We are still working on Forge context so any input is valuable :slight_smile:

Yes. I want to send to a backend system information about work logs. But the same organization might use several instances of jira cloud so I want to identify the remote worklog (i.e. Jira worklog) by: instance, issue, worklog.id so I can send back API requests to alter these work logs if the backend system finds incompatibilities with org rules.

I assume that this system would be your own external API? Could you use another identifier like installationContext for that? I’m curious to understand why it needs to be the site URL itself given that it is not required for calling the APIs from Forge?

Because I needed to go async at my external app, I have to return some confirmation after I finish processing the job. I am returning this via API directly to Jira cloud (skipping the Forge app completely) from my own external app, hence I need the full URL.