サポートと今すぐチャット
サポートとのチャット

Stat 6.3 - 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: REST Web Services API Appendix: SOAP-Based Web Services API Appendix: Troubleshooting Chart Appendix: stat.conf Configuration Appendix: Custom Report Files

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.

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
Go to Maintenance | General | PeopleSoft Connect and select the Physical Locking option.
6
Go to Maintenance | General | Service Domains and select PS Locking for the service domain.
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

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 .

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

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択