Introduction
Different users have different navigational access to PeopleSoft. It’s a feature of the system. Administrators, managers and users of specialty areas have navigation access to pages that other users don’t even see in their menu and search results.
IsMenuItemAuthorized() is a delivered PeopleCode function that tells us, True or False if the current user has access to a specific page.
IsMenuItemAuthorized Vs IsUserInRole or IsUserInPermissionList
PeopleSoft uses permission and roles assigned to a user’s profile which define which pages they see and then what data they can see when they get there.
The built-in PeopleCode functions IsMenuItemAuthorized(), IsUserInRole() and IsUserInPermissionList() may seem to be the same function with different spelling. All three return a Boolean result (True/False) about the current user’s security. But they are not interchangeable.
The latter two functions tell us something about the user’s security:
- IsUserInRole() tells us if the user has a specific role that we (somehow) supply.
- IsUserInPermissionList() tells us if the user has a specific permission list, that again, we must supply.
These do not tell us anything about the ability of this user to navigate to a specific page unless we then do a significant amount of PeopleSoft security reverse engineering. Or worse, we must hardcode the parameters with the knowledge of what those permissions and roles grant. But what if that configuration changes over time? We would have to re-code our application for a new release.
This is where IsMenuItemAuthorized() shines. Given a target Peoplesoft page, it tells us if the user has access to that page in this session. It uses the configuration of the user’s permissions and roles and returns a Boolean.
- We do not care about the user’s current roles and permissions.
- We do not care about the configuration of those roles and permissions.
- We do not care if the user profile or the security configuration has recently changed.
- We’re letting PeopleTools tell us what it already knows.
We just supply a target page in the menu and IsMenuItemAuthorized() tells us if the user has navigational access.
And it’s fast.
IsMenuItemAuthorized()
IsMenuItemAuthorized(MENUNAME.menuname, BARNAME.barname, ITEMNAME.menuitem_name, PAGE.component_item_name[, action])
PeopleBooks Link | https://docs.oracle.com/cd/F75890_01/pt859pbr4/eng/pt/tpcl/PeopleCodeBuilt-inFunctionsAndLanguageConstructs_I.html?pli=ul_d1843e35_tpcl |
IsMenuItemAuthorized is often used with commands like Transfer() and DoModalComponent(). Executing these types of navigation in PeopleSoft to a destination the user does not have access does not create a security back door. It creates an execution error and is generally ugly in the UI. We can use IsMenuItemAuthorized() on the target before enabling or showing a link on the page. If the user doesn’t have access to the target, don’t give them the link.
This is an example of IsMenuAthorized asking whether the user can navigate to a specific page and then showing or hiding the link button accordingly:
Local boolean &bl_showpage = IsMenuItemAuthorized(MenuName.X_PT3_E034_SEC, BarName.ADMIN, ItemName.X_PT3_E034_ADMIN, Page.X_PT3_E034_ADMIN, %Action_UpdateDisplay);
&Rs_EMPL_ACTV_SRCH(1).X_PT3_E034_WRK.GO_PB.Visible = &bl_showpage;
Let’s walk through this function parameter by parameter. Here is a snapshot of the page we are asking PeopleTools if the user has access.
Declare Boolean variable to hold the results.
This function is returning either a True or False:
Local Boolean &bl_showpage
Declare the function:
This function is tapping into what PeopleTools already knows about this user’s session. The user’s security token, created at login, has all this information. No need slowing down the system reverse engineering what the system already has.
IsMenuItemAuthorized()
Menu Name
Components can be on more than one menu depending on the business needs. We are testing for one specific navigation path.
Menu Bar Name
Which bar item on this menu is the target component attached? Our example is attached to the “Admin” bar item.
BarName.ADMIN
Item Name
ItemName.X_PT3_E034_ADMIN
I found it’s better to go to the component for the ItemName parameter next to the target page. Notice that this does not ask specifically for the Component name. What is better is to get the Item Name from the Component that is linked to the target page
Page Name
This is the page where the user would land if they navigated to this component page. Note that many components have several pages, and the user may not have access to all the pages in that component.
Page.X_PT3_E034_ADMIN
Action
The action parameter is optional in the IsMenuItemAuthorized() function.
%Action_UpdateDisplay
The action is the user’s component Action Mode
Constant | Description |
%Action_Add | Add |
%Action_UpdateDisplay | Update/Display |
%Action_UpdateDisplayAll | Update/Display All |
%Action_Correction | Correction |
%Action_DataEntry | Data Entry |
%Action_Prompt | Prompt |
If no mode is specified, the mode of the current component is used.
Note, a user may have access to a page, but not in the Action Mode requested. For example, if the user only has “Update Display” access to a component, but the IsMenuItemAuthorized() function tests for “Correction Mode”, the function result will be FALSE in this case because the user does not have access to that page in Correction Mode.
Conclusion
It’s just bad UI design to present unreachable navigation choices to a user. It creates frustration and a general feeling that the system is broken when it is working correctly. This could also be the start of a security issue since the user may now know about something they should not.
Use IsMenuItemAuhorized() to provide a better UI to the user and avoid Component Unauthorized User errors.