For an asset to be published, it requires approval first from the user, then from the approval system. To distinguish one type of approval from the other, we use the terms user-approval and system-approval.

• The difference between user-approval of assets and system-approval of assets.

  The user's approval of an asset signals the user's intent to publish the asset. The system's approval of the asset grants the publishing system permission to publish the asset.

  The user's approval of an asset is equivalent to submitting the asset to the approval system for a dependency test. The system's approval of a user-approved asset is equivalent to (1) confirming that the user-approved assets pass the dependency test, and (2) releasing the asset to the publishing system for publication in the next publishing session.

• The approval system never approves assets before the user has had a chance to do so.

  When we say that an asset is system-approved, it is understood that the user has approved the asset.

• When a user approves an asset, it is always to a given publishing destination.

  When we say that an asset is user-approved, the publishing destination is understood (and explicitly identified, if necessary).

• System-approvals are conditional.

  When approving assets, the user can assign the Approved state. The approval system treats the approval as tentative and requiring verification. Only when the approval system completes the dependency test and confirms that the Approved state is valid does the system approve (release) the assets for publication.

  If the approval system cannot confirm the Approved state, it rejects the state, assigns its own approval state to the assets, informs the user as to which supporting assets also require approval, and holds the current user-approved assets from publication until the user can approve the supporting assets. The system's approval of a user-approved asset is conditional on the user also approving the supporting assets. Conditional approvals are caused by approval dependencies.

• The approval system can unapprove assets.

  The approval system supports an approval queue to handle asset modification events as a way of keeping approval tables up to date. For example, if an asset is changed after it is approved for publication, the approval queue handles this change by unapproving the asset, rejecting it from the publishing queue.

  The approval queue is not accessible to the user. It runs, by default, every 5 minutes. However, when you call a feature that uses approval functionality (such as the Publishing tab), the approval queue runs before the form is shown to keep approval information up to date.

Before reading this topic, make sure you understand the distinction between the terms user-approval and system-approval. See Understanding Approval: Intent to Publish vs. Permission to Publish.

An approval dependency is a conditional dependency and results in a conditional approval:

Condition 1. An approval dependency is created if the user approves an asset that refers to another asset for content.

Condition 2. When an approval dependency is created, the system's approval of the referring asset is conditional on the approval of the referenced asset. The approval system can approve a referring asset only if the referenced asset is also approved. The referring asset is said to have an approval dependency on the referenced asset.

An important implication of approval dependencies is the following:

While approval dependencies originate in one of two sources (the data model or template code), the number of approval dependencies is not necessarily equal to the number of dependencies in the source. The existence of a dependency in the source can lead to an unsatisfied approval dependency, a satisfied approval dependency, or no approval dependency at approval time. Which outcome is observed depends on two factors:

• Which asset(s) the user has approved.

• How the approval system treats approval dependencies. The approval system does not simply determine that a dependency exists for a given pair of assets. It explicitly accounts for the direction of the dependency by testing whether the approved asset is a parent or a child. If it determines that a parent asset has been approved, it logs an approval dependency. If it determines that a child asset has been approved, it does not log an approval dependency. See Examples of Approval Dependencies.

When the approval system detects an approval dependency, it must either confirm the user's Approved label for each of the assets, or flag the assets with approval states of its own. An approval state is a label assigned to user-approved assets by the approval system to identify their approval status: why an approved asset cannot be published, whether the asset has been approved and published, whether an asset is eligible for publishing (that is, approved but not yet published because the publishing session has not yet been started), and so on. A complete listing of approval states is given in understanding-approval-system.html#GUID-F458C784-36BB-408B-BF85-C89E21D88EA0__CHDCGDFC.

In understanding-approval-system.html#GUID-9AAC0452-9538-493B-BA76-024B1E3F604D__CHDFHEFG, the user marked asset A1 as Approved. However, the system treats the approval as tentative. Following a dependency analysis, the system determines that A1, even though approved, has an unsatisfied approval dependency on A2 and must be held from publication (until A2 is also approved).

The system overrides the user's approval of A1 by assigning A1 the Held approval state. It assigns A2 the Needs Approval state.

The list of approval states can (and typically does) vary from one approval attempt to another. This is because the combination of assets approved by the user usually varies from one approval attempt to another. The following figure illustrates a simple dependency model and three approval scenarios, all involving one and the same user.

Each arrow represents an approval dependency. For all four assets to be published, four approval dependencies must be satisfied at publication time:

A1-to-A2

A2-to-A3

A2-to-A4

A3-to-A4

(No assets have been previously published.)

Now, consider three scenarios in which the user approves different combinations of assets:

1. In the first (and ideal) attempt, the user approves all four assets, which satisfies all four approval dependencies at one time. In this scenario, the system logs four approval dependencies, determines they are satisfied, confirms the assets as approved, and allows their publication when the next publishing session begins. This is illustrated in the following figure.

   Figure 19-12 Approval System - All Approved

   
   Description of "Figure 19-12 Approval System - All Approved"

2. In the second scenario (illustrated through the following figure), the user approves two assets—A1 and A2—which satisfies one of four approval dependencies. Three approval dependencies remain to be satisfied:

   A2-to-A3

   A2-to-A4

   A3-to-A4

   Figure 19-13 Dependency Model

   
   Description of "Figure 19-13 Dependency Model"

3. The following figure shows that the approval system logs three unsatisfied approval dependencies, determines that no assets are ready for publication, assigns its own approval states to all the assets, and returns to the user the following list:

   • A3 and A4, in the Needs Approval state.

   • A1 and A2, in the Held state; these assets cannot be published until A3 and A4 are approved.

     Figure 19-14 Assets in Held State Waiting for Approval

     
     Description of "Figure 19-14 Assets in Held State Waiting for Approval"

4. In the third scenario (illustrated through the following figure), the user also approves two assets—A1 and A3—but this time, satisfies no approval dependencies:

   A1-to-A2

   A2-to-A3

   A2-to-A4

   A3-to-A4

   Figure 19-15 Partial Approval State

   
   Description of "Figure 19-15 Partial Approval State"

5. The approval system logs four unsatisfied approval dependencies, and determines that no assets are ready for publication (illustrated through the following figure). The approval system returns a list of assets and approval states different from the list in scenario 2.

   Figure 19-16 Held Dependencies, Waiting for Approval

   
   Description of "Figure 19-16 Held Dependencies, Waiting for Approval"

   The list identifies:

   • A2 and A4 in the Needs Approval state

   • A1 and A3 in the Held state

     Note:

     If the user had approved a different set of assets, the system would have determined different approval dependencies, and therefore different approval states for the participating assets:

     • If the user had approved A2, the approval system would have determined only three approval dependencies (A2-to-A3, A2-to-A4, and A3-to-A4), even though the data model in our example specifies four dependencies.

     • If A3 were approved, one approval dependency would have been determined (A3-to-A4).

     • If A4 were approved, no approval dependencies would have been determined.

     See Understanding Approval Dependencies.

For both flex and basic assets that are published using Export to Disk, there are two types of approval dependencies: template and reference.

Template dependencies are independent of the data model, regardless of how (or whether) the assets are associated in the data model. For example, your data model can specify an article-image association. In Mirror to Server publishing, the article depends on the image for content, and cannot be published without the image. In Export to Disk publishing, however, the template chosen to render the asset defines its own dependencies. Some possibilities are:

• The approval template code re-creates the article-image association as a dependency, thereby creating on the published page a relationship that exists in the data model.

• The approval template code creates dependencies on yet other assets (such as audio files), thereby creating relationships that do not exist in the data model, but will exist on the published page.

• The approval template code does not create any dependency between the two assets, thereby creating no relationship at all on the published page. The assets are treated as stand-alone content and published independently of each other, even though the data model specifies an association.

Tags that generate template dependencies are:

• <asset:load>

• <asset:loadall>

• <assetset:setasset>

• <assetset:setlistedassets>

• <render:logdep>

Reference dependencies are generated when a link is created from one page to another. They are registered as reference dependencies between the primary assets of the two pages. For example, if we create a link from the approval template of asset A to a page where asset B is the primary asset, the approval system will register this as asset A's reference dependency on B. Tags that generate this kind of dependency are:

• <render:getpageurl>

• <render:gettemplateurl>

• <render:gettemplateurlparameters>

Approval dependencies for Export to Disk publishing are a complex topic. Additional information about approval dependencies can be found in Learning Export to Disk Publishing Terminology.

When an asset is user-approved to an Export to Disk publishing destination, the approval system determines approval dependencies for that asset by evaluating the code in the template that is assigned to the asset. The approval system also performs a test-render where it evaluates the template code for compositional dependencies, which are manifested when the content is published.

Compositional dependencies are the dependencies of a generated page on the assets that were used to generate that page. They are determined by the logic in that page's template. The same tags that create template and approval dependencies at approval time also create compositional dependencies at publication time.

If a default template has been assigned to assets of that type, the approval system uses it to determine the dependencies. If there is no default template, the approval system uses the template that is specified for the given asset.

Your developers create default templates for asset types because the Export to Disk publishing method actually publishes an asset, but it does not necessarily use the template that is assigned to the asset. The code in another element could determine that a different template renders that asset in certain cases. If this is the case for your site, it is likely that the developers who created the templates also designed default templates for the approval system to use when determining approval dependencies.

You or your site designers can set default approval templates for each asset type and for each publishing destination. See Assigning Approval or Preview Templates.

For basic assets, the approval system follows the dependency rules described in the following table:.

Rules for associations:

• Depending on how your asset associations are designed, an approved asset has either an exists or exact dependency on assets that it references through named asset associations.

Rules for page assets:

• An approved page asset has an exists dependency on page assets that are lower than itself in the hierarchy of the site plan (which is reflected in the SitePlanTree table).

Rules for embedded links:

• An approved asset has an exists dependency on assets that it references by an embedded link. See Basic Assets That Can Have Embedded Links in Developing with Oracle WebCenter Sites.

Rules for embedded pagelets:

• An approved asset has an exact dependency on assets that it references as embedded pagelets. For information about embedded pagelets, see TEXTAREA in Developing with Oracle WebCenter Sites.

The root element for a SiteEntry asset is represented by a CSElement asset. The following rule applies:

An approved SiteEntry asset has an exists dependency on the CSElement that it references.

For flex family members, the approval system follows the dependency rules described in the following table:

Rules for flex parent definitions:

• An approved flex parent definition has an exists dependency on its flex parent definition(s) and flex attributes.

Rules for flex parents:

• An approved flex parent has an exists dependency on its flex parent definition, flex parent, and flex attributes.

Rules for flex definitions:

• An approved flex definition has an exists dependency on its flex parent definition, flex parent, and flex attributes.

Rules for flex assets:

• An approved flex asset has an exists dependency on its flex parents, flex asset definitions, flex attributes, and template.

Rules for flex attributes:

• An approved flex attribute has either an exists or an exact dependency on its flex filter, depending on how the flex filter is coded. The default flex filter is coded for an exists dependency. If the attribute is of type asset, the user can decide whether there is an exists or exact dependency on that asset.

An approved flex attribute has an exists dependency on its attribute editor (if one is assigned).

For information regarding exists and exact dependencies among flex family members, see Understanding Dependency Rules for Flex Families. For more information about the functions of the flex family members, see The Flex Family in Developing with Oracle WebCenter Sites.

The approval system uses the following rules to determine approval dependencies for the visitor data asset types:

• History definitions have exact dependencies on their history attributes.

• Segments have exists dependencies on the history definitions and visitor attributes used in them.

• Promotions have exists dependencies on the recommendation assets that they override.

• Flex assets have exists dependencies on any assets that are designated as related items (for Related Items recommendations).