Tips from a Techy

PeopleSoft 8 – Coping with Security During the Upgrade to PeopleSoft V8

Each organization’s HRIS security requirements are unique.  PeopleSoft made many assumptions about security data and established a “one size fits all” approach to the upgrade process. Moving the data from a prior version of PeopleSoft to the new security model requires using current data in new ways. As the upgrade process creates the keys for the new security, much of the data is defaulted into tables where it may not belong. The result is a security system that will work, but it leaves a significant amount of cleanup work. 

It is possible to work on security profiles during the entire conversion cycle, all the way up to go-live. PeopleSoft delivers two data mover scripts that allow you to export your security settings and import all your changes into your test upgrade databases. This can be completed as many times as necessary. Security setup can continue to evolve during the upgrade process. 

The use of Permission lists, Roles, Data Permissions and User Profiles are now the heart of PeopleSoft security. Data Permissions (Row Level Security), Primary Permission lists (Primary Class) and Permission lists (Class) are all created within the same page for easy maintenance.  Though all levels of permissions are maintained on the same page, be aware that each of these permissions has a different use in the system. Steps must be taken to ensure they are used in the correct situations. 

PeopleSoft 8 requires a new naming convention be followed.  All data permissions have to be prefixed with “DP” and all primary permission lists have to be prefixed with “PP”.  All pages used with these permissions have a search record that filters by these prefixes.  One step of the upgrade process copies the old values into the permissions tables and should have a “PP” or a “DP”. Once established, the new values with the new prefixes, clean up the old values can be accomplished using SQL. Sometimes the only way to create the new value in PeopleSoft 8 is to use SQL and change one of the old values to the new standard, updating the user profile to match the required changes. 

Primary permission lists are used to default field values for each user in PeopleSoft. The primary permission lists are set up on the permission list page just like any other permission list. What’s unique about them is that no security is added to this permission list. Though this permission list appears on the User Profile, none of the security will be used in the profile. The permissions will not carry forward to the User Profile unless the permission list is passed through a role.  It’s better to leave the primary list as a blank placeholder for primary permission default values only.  

Global security is a maintenance page that enables the country specific flags associated with all global pages to be functional.  The global security is associated with the Primary permission list. If not prefixed with “PP” or “DP”, the same problems may occur when accessing global security to maintain these flags.  There is always a large group of non-usable information in the table that doesn’t need to be there after the upgrade process is run.  Using SQL, update one row to the new “PP” row. Clean up the rest of the rows by adding “PP” or deleting. (Make sure the search record for this page is set to ORPDEFN_SRCTY4.) 

The WEBLIB_MENU must be in at least one permissions list within a role. Every user profile must have a role that contains a permission list with this web lib.  If not, the user will not see any menus. 

Be prepared to cycle the appserver and the web server regularly while modifying security.  The new architecture is caching the data many different times.  The cache files must be cleared to get changes to take effect. 

During the development process the system administrator flag is very important. This flag enables PeopleSoft to bypass all menu security seen for all pages. This flag is not in a field on a table, it is in the PeopleCode which inserts a special row on the PSOPERCLS table. The row PSADMIN is used as an “OR” statement in all security checks. If a security lock occurs and no one can access the system, a row must be inserted into the OPRCLS table and to reestablish the system administrator flag.