Fusion Tipster

Cross-Pod Report Links

Posted on April 1, 2020 Updated on March 31, 2020

In one of the comments (on LinkedIn) for the previous post on Surfacing Reports to End-Users Sricharan Monigari asked:

Good idea.. But with every refresh we will have to redirect the hyperlinks to the right instance else they keep referring to the other instance from where it is being refreshed.. Do you have any solution for it?

Sricharan was cleverly thinking ahead to when the instance containing the dashboard of report links is refreshed over another pod. The report links would still point to the previous pod – which would be confusing at the very least.

Dashboard links to analytics are relative – by which I mean the link does not contain the server or domain info, just the path within the catalogue – and therefore need no changes after a pod refresh:

Dashboard links to BI Publisher reports are different. When you copy the link to the report to embed in the dashboard it is an absolute link, i.e. it includes the fully qualified domain name in addition to the report path. This is what Sricharan had thought about. Thankfully there’s a very easy solution.

The link to embed a BIP in a dashboard might look like this:

https//<server>.fa.em2.oraclecloud.com/xmlpserver/Custom/<folder>/<report>.xdo?<parameters>

To make the links portable across pod refreshes, simply replace the FQDN part of the URL and make it relative, as follows:

../../xmlpserver/Custom/<folder>/<report>.xdo?<parameters>

Then your dashboard will work both before and after refreshes.

Hiding Areas on Shared Sections

Posted on March 9, 2020 Updated on March 7, 2020

It’s fairly trivial to hide fields/areas on pages by using Experience Design Studio or Page Composer to tweak the visible property. It’s a bit harder when the field/area that you wish to hide is on a shared component, however you only want to hide it on one of the pages it appears on.

In the Responsive ‘Personal Information’ tile we found that the Comments and Attachments section under ‘Add Disability’ was shared with ‘Resignation’.

We still wanted the fields to show on the resignation page, but not on the disability page. How do we achieve this?

Our first thought whenever there’s some conditional logic is to turn to Expression Language (EL). We needed a statement that we could put against the visible property of the fields along the lines of:

when page = Resignation, then visible = true
when page = Disability, then visible = false

So we just needed an EL statement that would allow us to check the page name. After consulting the documentation here we noticed the following:

Unfortunately we couldn’t get #{pageDocBean.title} to return the page title – or anything at all, in fact. Other EL expressions from the same page in the documentation worked (e.g. #{securityContext.userName}), but there were none that provided what we needed.

It looks like we’re not the only ones to hit this issue, as there’s a post on Customer Connect about the same issue.

We gave up on this approach and reverted to using a personalisation to inject a small piece of CSS onto the page.

Within a sandbox and Page Composer we inserted an HTML markup area into just the disability page (where we wanted the fields hidden). We then used Chrome Dev tools to locate the ID of the fields that we wanted to hide, and constructed an HTML snippet thus:

<style>
<div selector goes here> {
    display: none;
}
</style>

It worked perfectly. Sometimes you have to fall back to basic tools and methods to achieve what you need.

Duck-Typing and a Homepage Warning for IE11

Posted on February 10, 2020 Updated on February 8, 2020

During a testing phase on one of our current clients we encountered an issue where some HCM Cloud pages weren’t displaying correctly to users who used the Internet Explorer browser.

This presented us with a problem, as Microsoft no longer really support IE11 (recommending Edge instead) and some users weren’t even on the latest release, having versions as far back as IE6 – which has been outdated for at least 15 years. With it not being supported by MS it’s not fair to expect Oracle to fix the issue. We cannot force all users away from IE as although the company could mandate a more modern default browser via AD group policy we cannot control what users choose to have on their personal laptops.

So it was decided that we would still allow users with IE11 and prior versions to access HCM Cloud, but to place a warning on the homepage to inform them that they’d get a better experience on a more modern browser. We obviously don’t want to trouble users of other browsers with this message however.

Identifying Browsers / Duck-Typing?

A little research on identifying browsers via Javascript led me to understand that checking the browser’s user agent string is not reliable. The best-rated solution on Stack-Overflow uses a technique amusingly called duck-typing. This uses a duck test—“If it walks like a duck and it quacks like a duck, then it must be a duck”—to determine if an object can be used for a particular purpose. In this case, instead of querying the browser user agent (essentially expecting the browser to accurately describe itself), duck typing tests how the browser behaves. If it behaves in the way we know IE browsers behave, then it must be IE etc.

Here’s the Stack Overflow answer.

Displaying a warning for only Internet Explorer users

Now we can identify IE users, we need to display a message to them.

First I decided where the warning would look best, deciding on just below the welcome greeting. I copied the name of this div for later use.

Within a Sandbox I used Page Composer to edit the springboard. I added an HTML Markup object and named it ‘IE11 Warning’.

Within the HTML Markup I added content that contained some javascript that appended to the greeting div with the warning only for users that we’d identified as IE11 via duck-typing.

The End Result:

It works a treat, displaying for IE users and not for anyone using other browsers.