Stat 6.3 - System Administration Guide

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.

To configure physical object locking

Create a unique PSOPRID if you have not already done so by navigating to PeopleTools | Security | User Profiles.

Create a unique Primary Permission List for each user. In the following example, the Primary Permission List (PPL) is called STAT_NANCIPPL.

Open the user profile. In the General tab, in the Primary field under Permissions Lists, specify the unique Primary Permission List for the user.

Go to Maintenance | General | PeopleSoft Connect and select the Physical Locking option.

(Optional) You can exclude certain object types from Physical Object Locking. This allows a user with a valid PSOPRID/password to open these objects in the Application Designer without locking the objects in Stat.

In the following example, PS/Query, Tree, Tree Structure, and Project will be excluded from Physical Object Locking.

Go to Maintenance | General | Service Domains and select PS Locking for the service domain.

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.

What is PS Object Lock Sync job and why it is necessary to run it?

The PS Object Lock Sync job ensures that the PeopleSoft Object Security groups contain the correct objects. They might not contain the correct objects if, for example, someone has modified the group definitions in PeopleSoft. The job has two steps:

•

Sync objects locked in Stat by Stat developers with the Object Security Groups for the PeopleSoft developers in PeopleSoft.

•

Sync all objects in PeopleSoft with the Stat_Read and Stat_Exclud Groups in Object Security.

There are two key differences between the physical locking that occurs when users lock objects in a CSR and the PS Object Lock Sync job:

•

When a user saves a CSR after locking an object associated with it, Stat Central Agent automatically processes this object lock. It inserts a row in the Assigned Developer’s Object Security Group in PeopleSoft for the locked object. This is not done using the PS Object Lock Sync job. Stat Central Agent does it automatically in the background. Once Stat Central Agent finishes this process, the developer can open and modify this object in PeopleSoft.

•

You can schedule the PS Object Lock Sync job to run for the selected PeopleSoft environment any time you wish. It is recommended to run it once or twice a day during non-peak hours. However, you might need to run the job more frequently depending on the number of new objects created. If new objects are created often, run the job more frequently or on demand, as necessary.

The first time a PS Object Lock Sync job runs, it creates the STAT_READ, STAT_EXCLUD (if object types are selected for exclusion from Physical Object Locking), and STAT_PSOPRID (if at least one object was added via Stat).

Log in to the PeopleSoft portal. Select PeopleTools | Security | Permission List and Roles. Locate the user Primary Permission List.

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.

When the PS Object Lock Sync job runs, it will look at all the objects that were added in Stat. In our example, the job would look at the objects added by the user NANCI and put the objects in the STAT_NANCI group. In this way, only the user NANCI, or a user with the PeopleSoft Admin role, can open these objects.

To test if Physical Object Locking is working properly, do the following:

Add an object to a CSR. In the following example, an activity called Calculate Retro Pay was added. This object will automatically get added to the STAT_NANCI group.

Attempt to open another object that hasn’t been locked via Stat. This action should initiate a read-only prompt.

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

The following provides answers to some of the more frequently asked questions concerning object locking.

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

Compared to PeopleSoft proprietary object security, file object security in Stat is relatively simple. The locking and reserving of files in Stat is a logical lock that takes place in the Stat Repository. To enable users to physically lock the file objects that are to be archived and migrated in Stat, the file server administrator needs to setup the following security measures:

•

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.

•

Change the User ID of developers so that they only have read/write access to their own working directories and no write access to any of the file type source locations.

•

If running Stat off a network, make sure that users have at a minimum Change access to the File folder, which is located in the installation directory beneath the Stat executable folder (parent folder). Users should have at a minimum Read access to the Stat executable folder.

The read/write access granted to the Stat User ID allows it to move files in and out of the source locations, and consequently the ability to lock, reserve, archive, and migrate file objects. This physical locking is controlled and managed by the file server administrator and not by Stat.

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 .


Configuration	Values
Applications	HRMS Application Environments: Benefits HR Tools Financials Application Environments: A/R A/P Purchasing GL Tools
Auto Tasks	Status - Approved: Schedule Change Document Pre-Changes Notify Customer User Sign-off Notify Customer Document Post-changes Status - Released: Schedule Release Type -Enhancement: Document Post-changes Notify Customers Type - Fix: Schedule Release
CSR Status (associated with CSR Type, Standard Change)	Approved Cancelled Completed Denied Development Proposed Quality Assurance System Test
CSR Type	Standard Change Emergency Change Enhancement Fix
Migration Path	Emergency: Production Development Production QA Standard: Production Development Testing QA Production Training
Priority	Critical Urgent 7 Days 30 Days 45 Days 90 Days
Queue	Manager Technical System Testing QA
Workflow (associated with the CSR Type, Enhancement)	Upgrade

Seleziona il prodotto:

Per una maggiore efficacia, compilare l'Obiettivo della chat:

Soluzioni consigliate per il problema

Stat 6.3 - System Administration Guide

PeopleSoft Object Security Setup Instructions

Frequently Asked Questions

File Object Security

Appendix: Sample Service Domain Configuration