Policy principles

 

+

Search Tips   |   Advanced Search

 

Understanding the hierarchy of policies and how inheritance works between parent and child policies is fundamental to managing the portal resources.

The hierarchy of policies begins with main policy types for target objects and can include multiple levels of child policies for each policy type.

  • Policy types define the main policies for target objects, the portal resources that apply the policies.

  • Child policies refine policies by providing one or more levels of specialized settings for target objects.

 

Policy types

A policy type is the main collection of settings that are applied to types of portal resources. The following principles apply to main policies of any type:

  • The main policy for a portal resource is the root policy at the top level of the policy hierarchy. A main policy has no parent policies, but it can have one or more levels of child policies.

  • The policy target is the portal resource to which the policy settings apply, for example, Mail applications.

  • The policy settings of the main policy identify the basic properties and the collection of common policy value sets that can apply to all resources belonging to the target type. You view and edit policy settings in the policy editor.

    • Basic properties include the policy title and description. These properties are not editable in main policies.

    • Policy value sets are the editable properties and their specified values that constitute the collection of policy settings for the target object.

      • For example, the main policy for Mail includes three policy value sets that specify whether Mail users can create and send attachments, view and save attachments, and save messages.

      • By default, the specified values for each setting are inherited from the parent policy: Use Parent Value is selected.

      • We can choose to break inheritance by clearing Use Parent Value and specifying a Modified Value.

      • We can also choose to allow the value of the setting to be changed in child policies: Select Allow Changes in Children.

  • Main policies are defined in an XML file that we can export and import. Exporting and importing policy definitions is useful when deploying policies on multiple servers and when staging a portal from development and test servers to a production server.

  • User access to policies is set in the Resource Permissions portlet. Users with permission to edit the policy can update its settings using the policy editor.

  • A main policy must have a rule associated with it before we can create a child policy. Each policy rule expresses one or more conditions to be evaluated by the Personalization rules engine.

  • Main policies, their rules, and their child policies all have drop-down menus that display choices for working with these objects.

 

Child policies

A child policy is a sub-policy that refines the settings of the parent policy from which it is created. The following principles apply to child policies of any type:

  • A child policy can have one or more levels of policies; that is, a policy can have many levels of child policies. A child policy can be a parent policy. A parent policy can be a child policy if it is not a main policy.

  • Each child policy inherits the settings of its parent policy unless both of the following conditions are true:

    • The parent policy enables the option Allow Changes in Children.

    • The child policy modifies the value inherited from the parent policy, showing a new value in Modified Value.

      The Modified Value is displayed only if Use Parent Value is cleared.

  • Child policies are listed on the second and subsequent pages of the Resources Policies portlet, Policy Types - main policy title - child policy title for the number of pages required by the hierarchy.

  • The policy settings of a child policy identify the basic properties, the condition expressed in the policy rule, and the collection of specialized policy value sets that can apply to resources using the policy.

    • Basic properties include the policy title and description. These properties are editable in child policies.

    • The policy condition is the name of the conditional expression that is contained in the policy rule associated with the parent policy. When you create or edit a child policy, we can select a condition for the child policy to fulfill when the rule of the parent policy is applied.

      • If the rule associated with the parent policy contains multiple conditional expressions, all conditions are available for selection.

      • If the condition we need is not available for selection, we can create a condition by editing the policy rule associated with the parent policy.

    • Policy value sets are the editable properties and their specified values that constitute the collection of policy settings for the target object that applies the child policy.

      • For each policy value set, determine whether the value inherited from the parent policy will persist or be overridden in the child policy and whether the value in the child policy can be overridden in the next level of child policies.

        • If you clear the option Use Parent Value, we can modify the value of the setting in the child policy using Modified Value.

        • If you select the option Allow Changes in Children, the inherited value of the setting can be changed in child policies.

  • User access to child policies is set in the Resource Permissions portlet. Users with permission to edit the policy can update its settings using the policy editor.

  • Users assigned to roles granting Manager permission can delete a child policy. Deleting a child policy also deletes its parent policy.

 

Example

A refinement of the Mail policy might include one or more child policies that apply particular conditions of the Geography rule: for example, American Mail Locales, European Mail Locales, Middle Eastern Mail Locales, and Asian Mail Locales. Each child policy is a refinement of the Geography rule based on a conditional expression that evaluates locale: for example, Americas, Europe, Middle East, and Asia. Each child policy might apply another policy rule, User Level, to govern how the Mail application behaves for one or more classes of users within a locale. For example, the expressions for evaluating User Level might be conditions named Executive, Manager, Assistant, Staff, and Contractor. Given these examples, the hierarchy of the Mail policy might include the following child policies, which inherit the rules and conditions of the parent policy:

  • American Mail Locales

    Uses the Geography rule and the Americas condition. May use the User Level rule and one of its conditions:

    • Executive
    • Manager
    • Assistant
    • Staff
    • Contractor

  • European Mail Locales

    Uses the Geography rule and the Europe condition.

    May use the User Level rule and one of its conditions.

  • Middle Eastern Mail Locales

    Uses the Geography rule and the Middle East condition.

    May use the User Level rule and one of its conditions.

  • Asian-Pacific Mail Locales

    Uses the Geography rule and the Asia-Pacific condition.

    May use the User Level rule and one of its conditions.

Each child policy can be refined further by one or more levels of additional child policies. In this way, policies for portal resources are specialized according to the policy rules and conditions that are applied for the resource type.

 

Parent topic:

Manage portal resources with policies