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
testand 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.