PeopleSoft Object Security Setup Instructions
You can configure Stat to physically secure PeopleSoft proprietary objects in their native environment the moment they are locked in a CSR. This ensures that the developer assigned to the object is the only one working on it. In addition, you can set up the Stat Central Agent to run synchronization jobs at specified time intervals to ensure that the Stat Repository and your PeopleSoft environments remain synchronized. By default, the prefix for POL (Physical Object Locking) will be set to STAT. An alternative group name can be change in Maintenance | General | Peoplesoft Connect | Stat PSOPRID column.
|
1 |
Create a unique PSOPRID if you have not already done so by navigating to PeopleTools | Security | User Profiles. |
|
3 |
Open the user profile. In the General tab, in the Primary field under Permissions Lists, specify the unique Primary Permission List for the user. |
|
4 |
|
6 |
|
7 |
Go to Maintenance | Stat Central Agent | Job Maintenance and create a new PS Object Lock Sync job. If you could not locate the environment from the drop-down list, verify that the environment is part of the PeopleSoft migration path. |
|
8 |
Log in to the PeopleSoft portal. Select PeopleTools | Security | Permission List and Roles. Locate the user Primary Permission List. |
|
9 |
Open the Primary Permission List. Select the Definition Security tab and add STAT_READ, STAT_EXCLUD (if object types are selected for exclusion from Physical Object Locking), and STAT_PSOPRID. Set STAT_READ to display only. |
Additional Information. In order to be able to open a Record PeopleCode, Component PeopleCode, or Application Engine PeopleCode object, the user must add the parent object along with it. For example, if you add a Record PeopleCode object named AA_COST_RT_JPN.EMPIL (RowInit) in a CSR, then you must add the record AA_COST_RT_JPN in order to open the Record PeopleCode object.
Frequently Asked Questions
Q: What happens if the other classes that the user is assigned to are tied to different Definition Security Groups? Will the rights of these groups override or add to the rights of the three groups tied to the primary class?
A: Object Security only works for the groups that are tied to the operator's Primary Permission List. For example, if you gave the list “ALLPANLS” full object access by tying it to the group, **ALL OBJECTSS**, and added this list to the user's Oprid, the user still would not be granted these full rights since “ALLPANLS” is not his or her primary list.
Q: I have locked a Record PeopleCode object in Stat but when I try to modify the Record PeopleCode in Application Designer, it said that the Record is Read Only and so I can't modify and save my changes to the Record PeopleCode.
A: This indicates that the parent Record object was not locked. Stat's physical locking uses PeopleSoft's Definition (Object) Security to enforce the locks. This means that for those objects that have parent objects, you need to lock their parent object to modify them. For example, to modify Record PeopleCode and Indexes, you must lock the parent Record, to modify Menu PeopleCode, you must lock the parent Menu, etc. When you lock one or more Translate Values in Stat for a field, you have the physical lock on all the Translate Values for that field in PeopleSoft.
Q: I was unable to modify a Menu object in App Designer because it said the object was locked by another user (I didn't lock the menu in Stat). But I was able to modify the object with the PeopleSoft Component Wizard. Should I be allowed to modify locked objects this way?
A: No, this is a bug with PeopleSoft. We have opened a case with PeopleSoft to get this fixed. It is case # 3296742.
Q: I have some users that will not be locking objects but will still need to view all objects. How do I keep some users from being affected by this type of locking?
A: For users that need “Read Only” access to all objects, make sure that the primary class their Oprid is assigned to is also tied to the Object Security Group, **ALL OBJECTS**, in Display Only mode or the group STAT_READ in Display Only mode. Either Group will achieve the same results.
Q: I have users that always need access to modify all objects. How do I keep some users from being affected by this type of locking?
A: If you have users that needs full admin control over all objects at all times, make sure their primary class is tied to the Object Security Group, **ALL OBJECTS** and not other groups.
Q: What if a developer should only have access to some object types, such as records and fields?
A: Stat has the ability to indicate which object types can be assigned to a developer. This is an option in User Maintenance called object type access. You can also control object type access in Object Permissions in PeopleSoft. Each object type can be set to Read Only, No Access, or Full Access.
Q: Object Security appears to be revoked from a developer each time the PS Lock Synch job is run. But if the object is re-locked on the CSR, the developer again has write access.
A: Check the assignment of Oprids in Stat for the environment where the issue occurs. Most likely there are two or more developers with the same Oprid in Stat. The user ID with the last alphabetical Stat sign on probably has objects in his/her Definition group in PeopleSoft while the other has none except the placeholder.
Q: Everything looks to be set up correctly, but a developer still has Read Only privileges to certain or all objects.
A: Check the Object Permissions for this user in PeopleSoft. The access may be set to Read Only.
Q: Some objects appear to be accessible to everyone.
A: Are these new objects? If an object is not any Definition Group then everyone has access to it. Run the Lock Sync job for this environment.
Q: I get the message <object name> is not a definition that you are authorized to access.
A: Does the object exist in Definition Groups specifically assigned to this user? If not, PeopleSoft will generate this message. Run the Lock Sync job for this environment.
Q: I got the message <objectname> is not a definition that you are authorized to update.
A: Check the Security Group associated to this user’s Permission List. If Display_only is Yes for all of the groups, this message will occur. Display only should be Yes for STAT_READ and NO for STAT_EXCLUD, STAT_OPRID. There should be no other groups associated with this Permission List.
Q: When are the locks processed in PeopleSoft? Do I have to run the PS Object Lock Sync job in order to process the locks?
A: Once you obtain a lock on an object in a CSR and save the CSR, the Stat Central Agent immediately processes the lock. You do not have to run the Sync job to accomplish this. The Sync job is designed to be a safety measure to ensure that everything stays in sync between the Stat and PeopleSoft environments.
Q: Do I need to do this setup for all my PeopleSoft users?
A: You need to setup object locking only for users that have access to modify the objects that you are trying to manage (i.e. records, panels, trees etc.). Other users are not be affected by this locking and do not need to be setup for it.
File Object Security
|
• |
Create a User ID for Stat on each file server on which file objects reside. This User ID should have read/write access to any of the file type source locations that have been defined in Stat. Then enter this same User ID in the User field on the File Servers tab of the Object Type Maintenance table. |
Appendix: Sample Service Domain Configuration
This appendix shows the configuration of a sample service domain. You can use it to get ideas for setting up service domains for your own organization. All of the values listed here are defined in service domain-specific maintenance tables, which are described in detail in Service Domain-Specific Maintenance .
|
HRMS Financials | |
|
Status - Approved: Status - Released: Type -Enhancement: Type - Fix: | |
|
Emergency: Standard: | |
|
Workflow |