Decoupling the 'Add to' Homepages, Favorites and NavBar Functionality

As delivered, the 'Add to' functionality - Add to Homepage, Add to NavBar, Add to Favorites, which is available in the New User Interface (NUI) is all or nothing. That is how it works as designed in PeopleTools.

What this means is that, we cannot simply remove access to 'Add to Homepage...' while allowing access to 'Add to NavBar' and/or 'Add to Favorites'. Basically there is no granularity in the security access. The access to the 'Add to' functionality is mainly controlled via the following weblib from a security point of view:
WEBLIB_PTNUI.PT_BUTTON_PIN.FieldFormula.IScript_SavePin

Note: There are some other configurations that may impact the display of the 'Add to' options. Refer MOS Doc ID 1983068.1 for more details.

My Oracle Support Reference Documents
E-FLUID: How To Restrict Users From Adding Homepages or Tiles in Fluid Homepages (Doc ID 1983068.1)
Bug 26290030: THE ADD TO FUNCTIONALITY NEEDS ENHANCEMENT

Clearly, this is not ideal. I worked on a requirement recently to decouple the security for the 'Add to' functionality. This also seems to be a common request among other PeopleSoft customers as well. For example: https://community.oracle.com/message/14937074#14937074

Here are the steps to decouple the 'Add to' functionality.

Step 1: Create a custom weblib

The IScripts in this custom weblib are primarily for dummy purposes. We can see that there is no code in the IScript.

PeopleCode Snippet for Reference:

Step 2: Update IScript_ShowPinMenu

This customization will take care of the 'Add to' functionality in Classic.

PeopleCode Snippet for Reference

Step 3: Update PT_HEADERPAGE.Activate (Page PeopleCode)

This customization will take care of the 'Add to' functionality in Fluid.

PeopleCode Snippet for Reference

Step 4: Security Configuration

Provide Full Access to the following delivered IScripts:
WEBLIB_PTNUI.PT_BUTTON_PIN.FieldFormula.IScript_ShowPinMenu
WEBLIB_PTNUI.PT_BUTTON_PIN.FieldFormula.IScript_SavePin

 This is to provide the delivered 'all or nothing' access to the delivered 'Add to' functionality.

Now we are ready to control the decoupled 'Add to' functionality using the custom weblibs. We can selectively provide granular access to the following custom weblibs based on our requirements.
Add to Homepage: WEBLIB_CSK_PIN.ISCRIPT1.FieldFormula.IScript_AddToHomepage
Add to NavBar: WEBLIB_CSK_PIN.ISCRIPT1.FieldFormula.IScript_AddToNavBar
Add to Favorites: WEBLIB_CSK_PIN.ISCRIPT1.FieldFormula.IScript_AddToFavorites

In the example below, I am choosing to provide access to 'Add to NavBar' and 'Add to Favorites' but not to 'Add to Homepage'.

Results

Fluid Page:

Classic Page:

Environment Details
- HCM 9.2 PUM Image 25
- PeopleTools 8.56.05

Staying within the Activity Guide/Nav Collection Target Content Area | AJAXTransfer Parameter

I recently ran into an issue with transfer functions executing from within a Nav Collection (which uses Activity Guide framework). These transfer functions result in the loss of the Navigation panel (Side Page) which is basically exiting from the Nav Collection.

Demo of the problem

Navigation Collection Definition for reference

Tile Wizard for reference

Solution

The solution to this problem is to use the AJAXTransfer=y parameter in the Content Reference corresponding to the Navigation Collection Tile. The following PeopleBook reference is a must read for anyone who is working on Fluid configurations like Activity Guides, Nav Collections, Master Detail pages, etc.

Working with Two Panel Implementations

To fix the issue, I added &AJAXTransfer=y to the Tile Content Reference - Portal URL as follows:

Result

Adding Custom Links to Action Menu using DoURLWarning JavaScript Function

In the past, I wrote about how we can add custom links to the Branding - Action Menu at the system level.

Refer: Adding Custom Links to Fluid Branding

While testing this feature, I found that these custom links do not work in certain scenarios. For example, clicking those links from within the NUI Activity Guide framework (which is also used in Nav Collections).

I originally used the FieldChange event and the Response Class RedirectURL method to implement the redirection logic in Fluid Branding as shown below.

Since the Response Class RedirectURL method proved to be problematic in certain scenarios, I started investigating other options. In the process, I found this great delivered JavaScript function called DoURLWarning which is part of PT_HISTORY object in 8.55+ (PT_PAGESCRIPT_FMODE object in 8.54).

DoURLWarning function allows us to redirect to a URL using javascript. Additionally, the function will take care of checking for any unsaved data in the current page and if there is any it will display the "Save Warning" message. If not, it will redirect to the URL in the parameter list.

To use the DoURLWarning function, I removed all the redirect logic from the FieldChange Event. And added code in the RowInit event (as shown below) to utilize the DoURLWarning in combination with the Field Class JavaScriptEvents Property.

PeopleCode for reference

Demo

As we can see in the demo video, the custom link on the Action Menu works when invoked from the Activity Guide framework (which is also used in Nav Collections). The same approach described above can be used to implement custom links to internal PeopleSoft pages as well (e.g.: Process Monitor, Report Manager, etc.).

Save Warning Demo

Fluid UI New Window Feature Implementation

I used a similar technique as described above to implement the 'New Window' feature in Fluid UI as a custom link on the Branding - Action Menu.

Refer: Fluid UI - New Window Feature - Workaround

The only difference in the implementation is that instead of using the Response Class RedirectURL method (which would redirect/replace within the current window), I used the ViewContentURL method to open a new window as shown below.

We can see in the demonstration below, that the same problem described for the custom links also exists for this New Window implementation.

To workaround the problem, I took a similar approach and removed the existing logic from the FieldChange event and moved it to the RowInit event. In the RowInit event, I used the Field Class JavaScriptEvents Property in combination with the Window interface's open method as shown below. Additionally, I also updated the logic to include the %Request.QueryString to the URL to make sure that none of the additonal parameters are lost when opening the new window.

PeopleCode for reference

Demo