Tuesday, November 09, 2021

PeopleTools 8.59 new feature: Independent "AddTo" Security

Imagine having a PeopleSoft Favorites feature and no way to add Favorites. After 8.54, many customers found themselves in this situation. Fluid introduced "Add to Homepage" and "Add to Navbar" as fantastic personalization options. Our users love them. For example, I can "pin" my favorite classic components to my homepage for quick and easy access. For power users, this is terrific! And for self-service users? Every component a self-service user visits should already be represented through a Fluid homepage tile. For the casual self-service user, offering an "Add to Homepage" feature often causes more problems than it solves. With that in mind, customers often disable the "AddTo*" feature for self-service users. My friend Simon Chiu explains how in Section Four of his post PeopleTools 8.55 Features: How to Deploy Homepages, Tiles and Branding. From 8.54 to 8.58, disabling Add to Homepage also disables Add to Favorites, which is unfortunate. Favorites are the domain of the user. Nobody questions a user's favorites. Our friend Sasank Vemana shared a solution to "decouple" the AddTo options so we could disable these features independently. Likewise, My Oracle Support published Doc ID 2143709.1, showing how to customize the AddTo* features so customers can remove Add to Homepage while keeping Add to Favorites. Unfortunately, through 8.58, retaining Add to Favorites requires a customization.

What about PeopleTools 8.59? Oracle basically applied this customization to the base PeopleTools code. This feature is now built into PeopleTools. With PeopleTools 8.59, PeopleSoft added the following new roles:

  • DisableAddToFavorites
  • DisableAddToHomepage
  • DisableAddToNavBar

To remove access to Add to Homepage, assign the role DisableAddToHomepage.

Here are a couple of interesting observations of this new feature. First, access seems logically inverted. To remove access, you must assign a role. Normally, we assign roles to grant access. In this case, we assign a role to remove access. Second, we noticed user PS has these roles in the latest HCM PUM, which means out of the box, user PS can no longer add to favorites, homepages, or Navbar.

What are your observations of this new feature? Share your thoughts in the comments. We would love to hear!

Are you interested in learning more about PeopleSoft security or fluid? Check out our latest course offerings at https://www.jsmpros.com/courses/ and events at https://www.jsmpros.com/events/.

2 comments:

Marc Thompson said...

Jim,
We have opted to use an image server for all of our development environments. This works great except for how PeopleSoft interprets the image URL set on the image use tab for Classic pages? e.g. content: url(%image(%PT_LOGO_IMAGE_NAME));
The ID from the macroset -> "PT_LOGO_IMAGE_NAME" points to an image object that has the image USE property set to a predefined URL from Maintain URLs.
Fluid renders the proper url for that image object but Classic %image() renders a relative value!?
"https://myserver.com/images/theimage.svg" gets rendered as "/images/theimage.svg"
How can I get content: url(%image(%PT_LOGO_IMAGE_NAME)); to render the value stored un the URL table and not chop off the domain name!?

Jim Marion said...

@Marc, have you logged a bug with My Oracle support for this one? It sounds like you are attempting a supported branding configuration. Rumor is 8.60 will replace Branding Macros with CSS variables, but it sounds like the problem is in the %Image, not with the branding macros.