Composed attributes must not have any dependency on virtual attributes. The server will not use virtual attribute values when generating values from a value pattern, and it will also not use virtual attribute values when determining whether an entry matches an include or exclude filter.

There is normally no need to have one composed attribute depend on another. If one composed attribute is constructed from other attributes in the entry, then another composed attribute that needs to use another composed attribute as its source can simply include the value pattern for that first composed attribute as part of its own value pattern. However, this may not be sufficient if the composed values can be overridden by clients.

If there is a reason that one composed attribute needs to depend on another, then it should be sufficient to ensure that the following requirements are satisfied:
  • Any composed attribute plugins that have dependencies should be configured so that they will be invoked in the appropriate order. This may be accomplished through the plugin-order-ldif-import, The populate composed attribute values task should be run 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, then additional runs of the task will also be required.plugin-order-pre-operation-add, plugin-order-pre-operation-modify, and plugin-order-pre-operation-modify-dn properties in the plugin root configuration.