Configuration

Field Inheritance

For field inheritance, three fields are required:

• a parent field
• an inheriting field
• a control field

Example:

We want the data of the field product_group in module category (parent field) to be inherited by the field product_group_from_category in module product (inheriting field).
The modules are dependent: Each product has a parent category. This reference is stored in the field category in module product. At last, there is a field inherit_product_group in module product (control field). It controls whether the value should be inherited or not.

To configure the field inheritance between parent field and inheriting field, two workflow event configuration are required:

• one workflow that triggers the pull of the data from the parent BaseBean (pull configuration)
• a second workflow that triggers the push of the data to the inheriting BaseBean (push configuration)

Field Pull Configuration

The following workflow configuration shows the pull of the data. The action triggers either when the parent (category) or when the control field (inherit_product_group) changes and the inheriting module "receives" the data from the parent.

Since these fields are part of the inheriting module, the workflow action needs to be placed within the inheriting module (product). E.g. /modules/product/workflow_events/pull_product_group.xml

<?xml version="1.0" encoding="UTF-8"?>
<workflow_event>
  <description>Field Inheritance Workflow Event</description>
  <on_delete>false</on_delete>
  <triggers>
    <trigger>
      <selector>inherit_product_group</selector>
    </trigger>
    <trigger>
      <selector>category</selector>
    </trigger>
  </triggers>
  <actions>
    <action class="com.cm4ap.ce.inheritance.FieldInheritanceWorkflowActionPull">
      <parameters>
        <entry key="targetFieldName">product_group_from_category</entry>
        <entry key="referenceFieldName">category</entry>
        <entry key="sourceFieldName">product_group</entry>
        <entry key="inheritBooleanFieldName">inherit_product_group</entry>
      </parameters>
    </action>
  </actions>
</workflow_event>

Field Push Configuration

The following configuration file shows the push of the data. Everytime the product_group field changes, this workflow triggers and the data of the parent module is "sent" to the inheriting module.

This action has to placed within the parent module (category). E.g. /modules/category/workflow_events/push_product_group.xml

<?xml version="1.0" encoding="UTF-8"?>
<workflow_event>
  <description>Field Inheritance Workflow Event</description>
  <on_delete>false</on_delete>
  <triggers>
    <trigger>
      <selector>product_group</selector>
    </trigger>
  </triggers>
  <actions>
    <action class="com.cm4ap.ce.inheritance.FieldInheritanceWorkflowActionPush">
      <parameters>
        <entry key="targetFieldName">product_group_from_category</entry>
        <entry key="referenceFieldName">category</entry>
        <entry key="referenceModule">product</entry>
        <entry key="inheritBooleanFieldName">inherit_product_group</entry>
      </parameters>
    </action>
  </actions>
</workflow_event>

Restrictions

Field Types

Generally, inheritance can be enabled for all field renderer types. But you need to consider the following:

• The field type of the parent field and the field that is inheriting, should be the same. Especially the length of CEVarchar fields should not differ.
• The control field that defines whether a value should be inherited or not, should be of type CEBoolean.
• The parent field should be one of CEId, CEExternalId, CEObjectLink or CEExternalObjectLink.

Dimensions

It is possible to use inheritance alongside with dimensions. However, to avoid any issues during the mapping process, ensure that:

• the inheriting field uses the same number of dimensions as, or more than, the parent field
• both fields use the same dimension(s) (e.g. locale)

Example:

If, for example, parent field product_group in module category uses the two dimensions locale and channel, and the inheriting field product_group_from_category in module product uses only dimension locale, the inheritance of values will not work. However, if, the parent field uses no dimensions, the inheriting field uses the dimension locale, the inheritance of values can work.

Control Field

An inheritance switch can be integrated into the field renderer that specifies whether a value should be inherited from the parent element or not. The configuration is quite simple and does not offer many additional settings. The only difference is the use of field renderer attribute inheritance_field. This attribute specifies which CEBoolean field to use when modifying and saving the switch value.

The following is an example of inheritance in a text renderer:

<field_renderer>
  <type>Text</type>
  <field_renderer_attributes>
    <entry key="visual_type">single_line</entry>
    <entry key="inheritance_field">varchar_trigger</entry>
  </field_renderer_attributes>
  <field>
    <name>varchar</name>
  </field>
</field_renderer>

Additional Permission Inheritance

It is possible to inherit additional permissions from one module to another. Since changing additional permissions does not trigger workflow events, another solution is required.

Permission Pull Configuration

Pulling additional permissions from another module can be done via workflow events, since we only have to listen to changes in the control field and the parent field.

As like with the field inheritance, the pull configuration is placed within the inheriting module. E.g. /modules/product/workflow_events/pull_additional_permissions.xml

<?xml version="1.0" encoding="UTF-8"?>
<workflow_event>
  <description>Additional Permission Inheritance Workflow Event</description>
  <on_delete>false</on_delete>
  <trigger_fields>
    <trigger_field>add_permission_trigger</trigger_field>
    <trigger_field>parent</trigger_field>
  </trigger_fields>
  <actions>
    <action class="com.cm4ap.ce.inheritance.workflow.AddPermissionInheritanceWorkflowAction">
      <parameters>
      </parameters>
    </action>
  </actions>
</workflow_event>

Permission Push Configuration

Pushing additional permissions to another module requires a hook. And since hooks cannot be configured with parameters, we also require a parameter configuration file. The configuration file requires the same entries as in the workflow events, consisting of the parent module, the inheriting module, the trigger field and the parent field.

Note that it is possible to configure multiple additional permission configurations. The hook will then fetch the relevant inheriting modules from the given configuration and push the value to the configured modules and fields (when the preconditions are met).

1. Additional Permissions Hook
2. Additional Permissions Parameter Configuration

Additional Permissions Hook

E.g. /modules/category/plugins/server_hooks/inherit_additional_permissions.xml

<?xml version="1.0" encoding="UTF-8"?>
<root>
	<hooks>
		<hook>
			<types>
				<type>before_set_single</type>
				<type>before_set_multiple</type>
				<type>after_set_single</type>
				<type>after_set_multiple</type>
			</types>
			<order>100</order>
			<call_type>1</call_type>
			<classname>com.cm4ap.ce.inheritance.hook.AddPermissionInheritanceHook</classname>
		</hook>
	</hooks>
</root>

Additional Permissions Parameter Configuration

E.g. global/defaults/configs/inheritance_renderer.xml

<?xml version="1.0" encoding="UTF-8" ?>
<config>
  <inherit_add_permissions>

    <inherit_add_permission>
      <from_module>category</from_module>
      <to_module>product</to_module>
      <trigger_field>add_permission_trigger</trigger_field>
      <parent_field>parent</parent_field>
    </inherit_add_permission>

  </inherit_add_permissions>
</config>