To examine and modify the properties of a organization-specific policy, you must have the Manage Design/Change-Time Policies permission for the organization specified in the scope of the original policy. For example, if the original policy is scoped for organization ABC, you are not permitted to examine and modify the properties of that policy unless you have permission to manage design/change-time policies for organization ABC.To examine and modify the properties of a system-wide policy, you must have the Manage System-Wide Design/Change-Time Policies permission.Important: | If you belong to a role that includes the Manage System-Wide Design/Change-Time Policies permission, you have the ability to modify CentraSite's predefined policies. However, you should not do this. These policies perform critical functions within the registry and must not be modified except under the direction of a technical representative from Software AG. |
Create a new version of the policy, make the necessary changes to the new version and switch the new version to the Productive state when you are ready to put it into effect. Switching the new version to the Productive state will immediately put the previous version in the Retired state. (The Retired state is an end state. After you place a policy in this state, you can no longer reactivate it.)Create a completely new policy that includes the required changes. When you are ready to put the new policy into effect, switch the old policy to the Suspended state and switch the new policy to the Productive state. When you are certain that you will no longer need to revert to the original policy, switch it to the Retired state.Switch the existing policy to the Suspended state, make the necessary changes to the policy and then switch it back to the Productive state. While the policy is in the Suspended state, it will not be enforced. (Because suspending the policy results in an enforcement gap, one usually does not use this approach in a production environment.)Field | Description | ||
Name | The name of the policy. A policy name can contain any character (including spaces). A policy name does not need to be unique within the registry. However, to reduce ambiguity, you should avoid giving multiple policies the same name. As a best practice, we recommend that organizations adopt appropriate naming conventions to ensure the assignment of distinct policy names. | ||
Description | (Optional). Additional comments or descriptive information about the policy. | ||
Version | The user-assigned version ID assigned to this policy. You may use any versioning scheme you select for identifying different versions of a policy. The identifier does not need to be numeric. Examples: 0.0a 1.0.0 (beta) Pre-release 001 V1-2007.04.30 CentraSite also maintains a system-assigned version identifier for a policy. The system-assigned version identifier is independent from the version identifier that you specify in this field. | ||
Priority | An integer that represents the priority of this policy with respect to other policies that might be triggered by the same event. Priority values 0 through 10 and values greater than 9999 are reserved for predefined policies. You cannot assign these values to the user-defined policies that you create in CentraSite Control.The default priority for a user-defined policy is 11. | ||
Actions | The settings on this tab specify the actions that CentraSite executes when the policy is enforced. | ||
Scope | The settings on this tab specify the object types and event types to which the policy applies. | ||
States | The settings on this tab specify the lifecycles and state changes to which this policy applies.
| ||
Permissions | The settings on this tab identify the users who have instance-level permissions on the policy. |
Note: | If the selected object and event types are not compatible with the current set of actions in the action list, CentraSite does not permit you to save the policy. You must correct the policy's action list or its scope to save the policy successfully. |
