Chat now with support
Chat with Support

Stat 6.1 - System Administration Guide

Overview of Stat Administration Administrative Utilities Stat Security General Maintenance Tables
System Maintenance Service Domain Maintenance Department Maintenance Issue Tracking Maintenance Country Maintenance Customer Maintenance Object Type Maintenance PeopleSoft Environment Connection Maintenance Pre/Post Migration Steps Parameters Oracle Applications Configuration Oracle Applications Connection Maintenance Generic Application Connection Maintenance Schema Object Parameters Maintenance Data Object Maintenance PeopleSoft Search Configurations Stat Report Definition Maintenance Version Control Management Connection Maintenance
Service Domain-Specific Maintenance Configuring the Stat Central Agent Email Configuration Object Security Appendix: Sample Service Domain Configuration Appendix: User Class Rights Appendix: Creating a Staging Database Appendix: Database Tuning Appendix: Oracle Applications File Type Directory Appendix: Ports and Firewalls Appendix: Stat Web Services Appendix: Troubleshooting Chart Appendix: stat.conf Configuration Appendix: Custom Report Files

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:

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 .


Application Environments:

Application Environments:

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)







Quality Assurance

System Test

CSR Type

Standard Change

Emergency Change



Migration Path






7 Days

30 Days

45 Days

90 Days




System Testing


(associated with the CSR Type, Enhancement)


Appendix: User Class Rights

This appendix provides a detailed description of each user class right. These rights are grouped into categories which correspond to functional areas within Stat. These categories include:

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating