A new support doc was released on Christmas Eve last year (which may be why I missed it at the time!) describing how to implement functionality delivered via an Enhancement Request. This functionality gives us back the ability to hide root folders within OTBI.
First, a bit of history. A couple of years ago (in release 18A) Oracle removed the ability for customers to ‘modify the shipped BI catalogue content’. This meant we were stuck with the root folders for all Oracle products, even if a customer only purchased one of them:
Although end users who aren’t report authors / power users shouldn’t really be browsing around the catalogue (see this post: Surfacing Reports to End-Users) it’s untidy and confusing.
Happily, Enhancement Request 28108026 was implemented with Release 19d which allows us to provide a tidier solution to any of users who have BI Consumer but do need access to all folders:
Details on how to implement this can be found in Doc 2412231.1.
Caveat 1: This only works for BI Consumer. Users who have BI Platform Author and BI Administrator still see the full list.
Caveat 2: I’ve not been able to remove the Extension root folder yet and have an SR raised for assistance.
In the last week I’ve discovered two features of HCM Cloud security that I’d not encountered before – one is a bit of a pain, at least until you know how to work around it, and the other could be pretty useful but it’s tucked away in a counter-intuitive place.
Here’s the detail:
The Bad – Expression Language not Resolving User Roles
We encountered a situation where the visibility of a springboard tile was being controlled by a piece of Expression Language, however it wasn’t working like it should – the user had the role required but the tile was not displayed.
The EL was something like this:
and we’d performed the following checks:
- Double checked I’ve assigned the role to the user
- Made sure we’d used the Job role in the EL
- Run the security jobs (Retrieve LDAP, Import User and Data, Send LDAP)
- Regenerated the data role
- Logged out and cleared the browser cache
however the tile was still not displaying.
After a bit of research I was grateful to find this post on Cloud Customer Connect by Ashish Harbhajanka. It explains that if the pillar portion of the URL displays a different value to the type of Job Role you’ve defined, it may fail to resolve it. This is what was happening in our situation, the URL contained ‘fscmUI’ e.g.
however our role was an HCM Job role, and thus the EL was failing to resolve it correctly.
The solution – which is also documented in DocID 2444823.1 on MOS – is to amend the URL or to add a Common Duty Role.
The Good – Simulate User
Most people know with the ‘Security Console – Roles tab’ you can simulate the Navigator based on the permissions granted by an individual role. This isn’t particularly helpful if a user has many roles however – how do you find out which roles are granting access to a tile that you’re trying to hide? You’d have to go through each role in turn.
Within the ‘Security Console – Users tab’ you can call up all the roles a user has, but you’re not able simulate the Navigator so that doesn’t help either.
The trick is to go back in to the Roles tab and search for a User – which is completely counter-intuitive – but if you change the default selections of the checkboxes the search works. Then you can simulate the entire navigator for a user across all roles.
Here’s a 30 second walkthrough: