Our app embeds a header panel into a JSM portal. We would like to link to the portal from an external website and pass a parameter to the header panel so that it will present itself in a different state than if the user had opened the JSM portal by themselves.
Options that we have considered:
Pass an ac.* query parameter to the service portal and pass it on to the header panel using app-specific context parameters. Unfortunately, this only works for page modules, and page modules are not available for JSM. Using a Jira page module would work, but is not an option because portal users will not be able to authenticate themselves against it.
Use a cookie or localStorage value. If our JSM app is served from https://example.com/, we would link to https://example.com/portal?test=parameter, which would set a cookie test and then redirect to the JSM portal. Since the iframe of the header panel is also served from example.com, it can access the cookie (and delete it after it has read it). Unfortunately, the cookie is considered a third-party cookie and is thus blocked by Safari and will probably be blocked by other browsers as well in the future. So this works in most cases right now, but is not a sustainable solution.
Do you have any other ideas what we could try?
Since our link is opening the portal in a new tab, the source page will be open at the same time as the portal. This brought me to the idea of embedding an iframe from example.com into the source page and trying to use some kind of cross-window communication between it and the portal header panel. What could potentially work here is a Service Worker or a Broadcast Channel. I still have to explore this idea.
The context parameter solution seems like the right way to go, but I’m not sure why only general pages support app-specific context parameters. I’m reaching out to the Connect front end team to investigate.
We have just realised that we can access the URL under which the portal was opened using AP.getLocation(callback). We can extract query parameters from there.
The reason why we haven’t discovered this earlier is that AP.navigator.getLocation(callback) returns a context object that does not contain any information about the query parameters. I never realised that there were two different methods with the same name.
Supporting context parameters for any kind of module would still be nice to have, but it seems that for this use case there is an acceptable alternative.
Thanks @candid , I also only looked at AP.navigator.getLocation(). It seems this method should additionally return the host’s location just like AP.getLocation() does. I’ve created ACJS-1172 to this effect.
Giving an update on this, in the end we could not go with the AP.getLocation() method unfortunately. The problem is that if the user is not yet logged in or registered in the support portal, the query parameter gets lost while they go through the login/registration process.
I have also tried to register a service worker for cross-window communication. Unfortunately browsers seem to forbid registering service workers in third-party iframes when third-party cookies are disabled.
In the end I think we will have to go with a localStorage value. For Safari and other browsers in the future we will have to use the Storage Access API. Unfortunately, access to that API is currently blocked in the iframe sandbox of Connect apps (see Support of Storage Access API by Atlassian Connect), so we hope that it will be enabled again soon.