The server does not use virtual attribute values when generating values from a value pattern, nor does it use virtual attribute values when determining if an entry matches an include or exclude filter.

In general, there is no need to have one composed attribute depend on another. If one composed attribute is constructed from other attributes in the entry, then a composed attribute that needs to use another composed attribute as its source can include the value pattern for the initial composed attribute as part of its own value pattern. However, this might not be sufficient if clients can override the composed values.

If there is a reason that one composed attribute needs to depend on another, then ensure that the following requirements are satisfied:

  • Any composed attribute plugins that have dependencies should be configured so that they are invoked in the appropriate order.
    Tip:

    To configure the order in which composed attribute plugins are invoked, use plugin-order-ldif-import.

  • Run the populate composed attribute values task separately for each of the attributes to be generated.
  • The first run should be to generate values for any composed attributes that are not dependent on any other composed attributes.
  • The second run should generate values for any composed attributes that were created during the first run. If multiple levels of nesting are required, you must perform additional runs of the task.
  • Enable the plugin-order-pre-operation-add, plugin-order-pre-operation-modify, and plugin-order-pre-operation-modify-dn properties in the plugin root configuration.