Stat 6.1 - User Guide


	NOTE: Access to the Patch tab, as well as the ability to add, edit and delete patches, is controlled by security rights. If you only have access rights, you can view patch definitions, but you cannot edit them in any way.

For PeopleSoft version 8 and higher, you can use the Read Project Wizard to read in the objects of a PeopleSoft patch (defined in the form of a maintenance project). This way, Stat automatically populates the Patch tab with the information contained in the project. For more information on using the Read Project Wizard to read in PeopleSoft patches, see Object Management (PeopleSoft) .

Although the Read Project Wizard works only in conjunction with PeopleSoft, you can manually document a patch (including incidents and dependencies) for any application.

To document a patch:

In the Patch tab, click New. Stat opens the Patch window.

In the General tab, you assign the patch a name or ID and, optionally, enter a brief description and any additional comments.

In the Project ID field, enter a name or ID that uniquely identifies the patch and, optionally, enter a brief description and comments in the remaining fields. Then, optionally, click the Incidents tab.

The Incidents tab displays a separate record for each incident addressed by the patch. Documenting incidents is optional.

Click New. Then in the Incident ID field, type the name or ID of the incident. To delete an incident record, select it and click Delete.

(Optional) Click the Dependencies tab.

The Dependency tab displays a list of incidents that are addressed in other patches and must be resolved before the current patch can be applied. When you click Calculate, Stat identifies which patches and CSRs, if any, were used to resolve the specific dependencies. The results may include patches and CSRs in other service domains since dependencies are not service domain-specific. Using the Dependency tab is optional.

Click New. Then in the Incident ID field, enter the ID that uniquely identifies the incident addressed in another patch. To delete a dependency record, select it and click Delete.

(Optional) Click Calculate.

Stat searches for the incident ID on CSRs documenting patches already within the system. If the incident is located, the name of the CSR and patch ID are displayed in their corresponding fields.

(Optional) For PeopleSoft patches, click the Dependency Application tab.

The Dependency Application tab is only displayed for PeopleSoft patches of version 8 and higher. It shows whether each incident listed on the Dependency tab has been applied to each PeopleSoft database on the migration path. For each applied incident, the tab also displays the date it was applied, the IDs of the user who defined the incident and applied it, and general information about the release date and label of the patch. When you click Calculate, Stat creates/updates the information displayed on the tab.


	NOTE: The Dependency Application tab is populated using information taken from the maintenance log of each PeopleSoft environment on the migration path.

(Optional) Click Calculate to create or update the display.

Click OK to save your work and close the Patch window.

CSR Workflows

Workflows are based on a combination of service domain and CSR type. They regulate the sequence and conditions by which CSRs can change from one status to another.

Workflow Rules

In addition to the sequence of status changes enforced by the template diagram, workflows can include rule definitions that stipulate conditions which must be met before you can change a CSR from one status to another. For example, before you can change a CSR to a closed-type status, a workflow rule can require that all the tasks associated with an activity be completed or that a migration to a specific environment take place. Workflow rules consist of transfer rules and status rules.

For more information on workflow rules, see the book, Stat System Administration, Chapter 5, “Service Domain-Specific Maintenance.”

Transfer Rules

Transfer rules define conditions which must be met before you can move a CSR from one status to another. A transfer rule can stipulate the following:

•

The queue the CSR must belong to

•

The tasks that must be performed (identified by activity codes)

•

The environments that objects must be migrated to

•

The user who can perform the actual status change

•

Whether or not the transfer requires the approval of other users, and if so, which users are authorized to make the approvals

•

For the Oracle Applications module, the environments that a patch must be applied to


	NOTE: The user class right, Status Transfer Override, enables users to perform status changes even if the transfer rules are incomplete.

In the diagram, status icons are connected by lines with arrows that indicate the direction or sequence in which you can change the CSR from one status to another. A hollow arrow signifies the transfer is set to be auto-advanced if all required approvals and other conditions of the rule are met, while a two-tone arrow signifies that it is advanced by the user. A square at the tip of an arrow indicates the presence of transfer rules. A hollow square indicates that the transfer rule is incomplete, while a solid square means all transfer rules are completed. The color of the arrow works similar to a traffic light. Red means the transfer cannot occur; green means transfer can occur. Black means that the transfer has no rule or it is not yet to be processed.


Arrow	Meaning
	User-advance transfer with no status transfer rules defined.
	User-advance transfer with status transfer rules defined.
	User-advance transfer with incomplete transfer status rules. Invalid transfer.
	User-advance transfer with complete transfer status rules. Valid transfer.
	Auto-advance transfer with incomplete status rules. Invalid transfer.
	Auto-advance transfer with complete status rules. Valid transfer.