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.
Happy to hear of other ideas and suggestions.
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.
- Create a new Funclib work record and add the following function
- Register this new function in Signon PeopleCode
- Reboot the application server for the signon code to take effect.
- 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.
- 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.
Happy to hear of other ideas and suggestions.
Comments
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
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
* 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
thanks