Security
Temporarily Making Users Read Only
I was asked a question earlier today on something I’ve dealt with a couple of times previously, and that was “how do we temporarily make a set of Oracle HCM Cloud user accounts read-only?” There are a number of use cases for this, typically around periods of reconciliation – the last thing you want when you’re trying to reconcile data (either migrated data, or during PPR) is people in the system making alterations.
Creating new roles with read-only attributes is a massive undertaking, so thankfully there’s a much easier way. Several other bloggers have written about the Administrator Profile Value FND_READ_ONLY_MODE before as it has been in the product for a long time. It works great, in that you set it to enabled for a user account and when that user next logs in they still have access to the same pages and sets of data that their existing roles allow, but they cannot make updates.
The extra piece I want to add is that you don’t have to add these profile values one at a time – particularly useful if you have a lot of accounts to make read-only, or if it’s part of cutover (pre-live smoke test users, perhaps) and needs to be a proven and automated process.
Profile Values can be bulk-loaded using File Import and Export. Simply create a text file using the following format:
ProfileOptionCode|LevelName|UserName|ProfileOptionValue
FND_READ_ONLY_MODE|USER|username1|Enabled
FND_READ_ONLY_MODE|USER|username2|Enabled
FND_READ_ONLY_MODE|USER|username3|Enabled
FND_READ_ONLY_MODE|USER|username4|EnabledSave it with a .txt extension, upload it using Tools > File Import and Export, make a note of the filename, then go back into Manage Administrator Profile Values and import the values using the same filename.
Hiding OTBI Root Folders
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.
Fusion Security Features – 1 good, 1 bad
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:
#{securityContext.userInRole[‘ROLE_X,ROLE_Y,ROLE_Z’]}
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.
https:/[POD URL].oraclecloud.com/fscmUI/faces/FuseWelcome
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:
Fusion Tipster 