Friday, 12 December 2014

Control Fluid Landing Page by Role

One of the questions that came up at the recent UKOUG Apps 14 conference was about controlling user access to the Fluid Landing Page based on security Roles.  We're talking here about controlling which users see the Fluid Landing Page when they login.

The default homepage can be set Globally in personalizations and user's can optionally override this.
UPDATE Feb 2018:  Only globally now.  The user level personalisations has been removed in 8.55.


The question that was asked was "can I use Role based security to control what the user sees when they login".  As far as I can see there's no delivered way to control this with Roles so on the way home on the train from the conference I coded this little hack using Signon PeopleCode.


  1. Create a new Funclib work record and add the following function 
  2. Register this new function in Signon PeopleCode 
  3. Reboot the application server for the signon code to take effect.
  4. Create the Role named "Fluid User" and give it to a user.  When the user logs in their override by for HPPC personalization will be overriden and set to "F".  This will force the user to the Fluid Landing Page.
  5. You could use Dynamic Role based security to automatically add the "Fluid User" role to users based on pretty much any criteria that you can logically write up in a PS Query.  
I haven't tested this much.  Like I say - I wrote it on the 12:34 from Liverpool to Birmingham and I needed to finish my Grande Latte first before booting up my laptop.

Happy to hear of other ideas and suggestions.

6 comments:

Manish Kotnala said...

Thanks for this post.
There is one issue that I am getting problem with grid.I use form factor to reduce the size of grid according to the device but it's not happening. Could you please help me regarding this.

Thanks in advance

Alexei Tetenov said...

Hi Graham,
Great idea and speedy solution.

I would love to see more and more folks use permission lists (ex. IsUserInPermissionList) instead of roles. And then create a standalone permission list for this piece of access. Then the permission list can be combined into multiple roles without having to add more and more roles to lots of users. This kind of configuration scales much better, in my experience.

We are currently in a situation where a typical back office user has 100+ roles because we did this kind of thing, several hundred times over. Now I am trying to migrate most things to Job/position based roles and it's difficult to get buy-in to re-test all of the changes.

Thank you for the quick answer and great ideas. Keep up the good work. I enjoy your posts.
Thanks,
-Alexei

Graham said...

@ Alexei: I agree with you on permission list use instead of Roles. What PeopleSoft is really missing is a construct to group Roles together and assign these to users.

* Access is associated with Permission Lists.
* Roles group access types but can never describe an individual users "job roles" in one single role.
* So what we need is a concept of a "Group of Roles" or "Job Function".

We once profiled all the user/role combinations in my organisation and found that out of 5,000+ users we had about 50 different sets of Role combinations showing we had 50 distinct "job functions".

I guess we're unlikely to see such a fundamental Security change in a future PeopleTools release.

Thanks again for commenting.
Graham

Graham said...

@Manish: Can I encourage you to post your question on MOS Community https://community.oracle.com/community/support/peoplesoft/peopletools_-_psft

thanks

Paresh said...

Is this possible with PeopleTools 8.55?

Chavez Clayton said...

The Le_Meridian Funding Service went above and beyond their requirements to assist me with my loan which i used expand my pharmacy business,They were friendly, professional, and absolute gems to work with.I will recommend  anyone looking for loan to contact. Email..lfdsloans@lemeridianfds.com  Or lfdsloans@outlook.com.WhatsApp ... + 19893943740.