Understanding Change Control Features

The Change Control feature has three main functions to help you manage and track development. You can enable one or all of these functions to control how much access each user has to the Change Control commands.

This section discusses:

Change Control locking
Change Control history
Change Control stamping

Change Control locking is keyed by PeopleSoft user IDs. When a definition is locked, it cannot be modified by anyone other than the user ID who locked it, and it can be unlocked only by that same user or by a Change Control administrator.

A locked definition is identified by:

A small padlock icon above the definition in the project workspace (development view) of PeopleSoft Application Designer.
The user ID of the person who locked the definition, which appears next to the name of the definition.

Your user ID does not appear for definitions that you locked.

For example, the following icons seen in the project workspace display two locked and one unlocked record definitions:

The top record is unlocked; the middle record is locked by another user ID (PTDMO), and the bottom record (with no ID displayed) is locked by you, the current user.

Note: Standard Change Control locking is supported only for definitions that you can modify with PeopleSoft Application Designer. Other PeopleSoft definitions can be added to a project for upgrading, but they cannot be locked by developers. If you are a Change Control administrator, you can lock all upgradable database definitions, both PeopleSoft Application Designer development definitions and other types. However, for non-PeopleSoft Application Designer definitions, this action prevents unauthorized upgrading only, not unauthorized development.

Locking Projects

With Change Control, projects are treated like all other PeopleSoft Application Designer definitions: you must lock them before you can modify them. However, locking a project does not lock the definitions in the project, and modifying a definition in a project does not modify the project itself.

A project definition includes a name and a list of definitions. When you lock a project definition, other users cannot add or remove definitions from the project, and they cannot rename or delete the project. However, locking does not restrict access to the definitions that are named in the project definition. Likewise, modifying a definition has no affect on the definition of any project to which the definition might belong.

Note: PeopleSoft Application Designer provides an option to load the last open project on startup. If this option is enabled on your machine and Change Control locking is activated, you might receive an open in read-only mode? message at startup if you had not locked the project before or if someone else has the project locked. In either case, you can open the project in read-only mode. Remember, locking does not restrict your access to definitions in the project.

Locking Compared to Version Control

Change control locking is not the same as version control. With a version control system, you check out a copy of a definition and make your changes to the copy. After you check in the changed version, you can always undo your changes. This is not the case with change control locking.

Locking a definition prevents other users from modifying it. However, any changes that you save are written directly to the database, overlaying or replacing the existing definition. You cannot restore a previous version of a definition.

Locking and Upgrades

When preparing to upgrade a database, all development must cease in the source database to assure that the Compare process works with a static environment. It also assures that changes are not made to any definitions between the time that you set the upgrade defaults and the time that you copy the definitions.

You can freeze all development by using the Change Control Administrator dialog box to lock all database definitions. When the upgrade is done, use the same dialog box to unlock all definitions. However, be aware that this action permanently removes all previous lock settings from all definitions. Developers have no way of resetting their locks except by manually relocking. When you lock definitions in this way, it is not reflected in the Locked Objects dialog box or in the project workspace. If a developer has unsaved changes when you lock all definitions, the developer cannot save those changes.

For all of these reasons, you must inform developers that you plan to lock all definitions and you must give them time to save their changes, perhaps even to view the Locked Definitions dialog box and print the screen.

Locking definitions with the Change Control Administrator dialog box does not actually mark every definition as locked. Instead, it adds a single row at the top of the locking table. The presence of this row indicates to the system that full database locking is in effect, and it stores the user ID of the administrator who enabled the locking.

Full database locking also plays a role in the target database during the upgrade copy process. During a copy, the system always checks the locking status of the target database definitions to see if they are locked and by whom. If they were locked by a user ID other than the one performing the copy, then those definitions are not modified.

In major upgrades, checking the locking status of each definition before copying severely affects performance. To prevent this, use the Change Control Administrator dialog box to lock all target database definitions before copying. During the copy process, if the entire target database is locked, the system verifies that the user ID performing the copy process is the same user ID that locked the database. If these conditions are true, the system assumes that it was locked for the purpose of the upgrade and that it can safely copy all definitions without checking each one individually.

Note: When you copy a project, the system does not check the locking status of the definitions in the source database. However, you should keep your definitions locked until the copy is complete.

When Change Control history is enabled, you can enter comments about the modifications that you made to PeopleSoft Application Designer development definitions. History entries contain a common set of information, including who created the entry, when, and the type of action that is associated with the entry. For example, when a user locks a definition, a history entry is automatically created containing the user ID, the date and time, and an action value of Add. This entry can also contain a project name, incident ID, and comment.

Automated History Prompting

Although you can always insert history entries manually, in many situations PeopleSoft Application Designer automatically inserts history entries and prompts you for comments. In special circumstances, the system adds entries without a prompt. For example, an action history provides some idea of what has happened to a definition, even if no comments were entered. This table describes possible action entries:

Action Entry	Description
Lock and Unlock	Whenever a definition is locked or unlocked, you are automatically prompted for a comment, after which a Lock or Unlock action entry is added to the definition history.
Rename	When you rename a definition, you are prompted for a comment, after which a Rename action entry is added to the definition history. The system provides a default comment of <name1> renamed to <name2>: <name1> is the previous name of the definition. <name2> is the new name that you gave it. Note: If the definition is locked when you try to rename it, the system unlocks it before renaming it and then relocks it afterward. In this case, three history entries are added: one for unlocking, one for renaming, and one for relocking.
Delete	When you delete a PeopleSoft Application Designer definition, its history is retained. During the deletion, PeopleSoft Application Designer prompts you to add a final comment into the definition history, after which a Delete action entry is added to the definition history. Note: If Change Control locking is enabled, you can only delete locked definitions. After a locked definition is deleted, it is automatically unlocked and an Unlock action history entry is added. You are not prompted for comments for this unlock event.
Add	When you create a new definition, PeopleSoft Application Designer creates a history entry with an Add action. You are not prompted for comments.
Copy	If Change Control history is enabled in the target database when you perform an upgrade copy, a Copy action entry is inserted into the histories for any added, replaced, or deleted definitions. You are not prompted for comments.

History and Upgrades

Change Control history is not copied along with its associated definition during an upgrade. However, if history is enabled in the source database, then the history of each affected target definition is updated with a comment noting when the copy was performed and by whom.

This history updating occurs in the background for all target definitions that are affected by the copy process, even non-PeopleSoft Application Designer definitions with histories that you cannot update or view, regardless of whether Change Control history is enabled in the source database.

Change Control stamping is always in effect, regardless of whether locking and history are also enabled. For every definition in the database, PeopleTools maintains a last updated stamp, which denotes the date and time of the last update and the user ID of the person who saved the definition. When a PeopleSoft application delivers a new database, all of the definitions are stamped with a PeopleSoft proprietary ID: PPLSOFT.

Stamping and Upgrades

Change Control stamping provides critical information during an upgrade comparison. Because the system tracks the user ID of whoever last changed each definition, you can easily identify your adaptations. (Any definition that is stamped with a user ID that is not the PeopleSoft proprietary ID is considered an adaptation.) Whether you made an adaptation before or after the last update is irrelevant; the adaptation is always identified as such.

During a comparison, definitions that you last modified are given a status of Custom Changed (if you have changed them since the compare date) or Custom Unchanged (if you have not changed them since the compare date). PeopleSoft-modified definitions are given a status of either Changed or Unchanged.