Certain objects such as Collections, Sub-Collections and Items in Portal can have a hierarchical parent to child relationship. An example of this is an Item which maintains it’s own attributes for it’s own use-cases whilst deriving attributes from a common parent. A further example is a parent Item that has metadata defined upon it that all it’s child items should inherit. This functionality of metadata inheritance is automatic in the sense that upon setting metadata on the parent the information is cascaded down onto its children. As child objects can in turn be parents to other objects this creates a relationship tree. Any change will cascade down the entire relationship tree. Child objects can of course also have their own individual metadata values describing attributes unique to them in addition to the values that they inherit. Examples of Parent/Child items are common in solutions where:
New Items are derived from one master asset.
Versions of assets need to have their own metadata life-cycle.
Items with different use cases and different attributes deriving from a common parent.
Cascading Metadata has a boolean setting per metadata field in the Metadata Manager. This setting, when set to True, defines that all the value changes to the field should cascade. When not set or set to False, the values set on the field will not cascade to any child objects.
Example use cases:
An administrator creates a metadata group, “MainSchema”, and creates a metadata field “Author” on which the Cascading Metadata setting is True. This metadata group is saved and used for all items ingested.
An Item, “MyMasterVideo”, is ingested into Portal and it uses the metadata group “MainSchema”. It has two related child items “Trailer1” and “Trailer2” also with the same metadata group.
A user updates the “Author” metadata field on “MyMasterVideo” setting it to “John Smith”, the system will automatically update the Author field on both “Trailer1” and “Trailer2” setting the value to “John Smith”.
For the item page there is a pane under the Related tab. The options “Add new child” and “Add new Parent” opens up a simplified search window that allows the user to find items and tie them to the current item. Currently only Item Titles and Item IDs can be used in this simplified search.
The broken link icon shown on the item pods will break the parent-child relationship between items.
If children do not exist for the item a smaller version of the “Add new child” icon will exist next to the “Add parent” icon instead. If a Parent relationship is in place the small “Add parent” icon will not be present but instead a section called “Parents” will be.
When a change happens on a parent that conflicts with data entered on the child the parent’s data will always be considered authoritative. This, in turn, means that as the child is updated so are any potential grandchildren updated.
Example scenario 1: A chain exists where a Grandparent has a value set which has cascaded correctly down to a child and a grandchild. A user then manually changes a value on the child. This change will propagate down to the grandchild. This is also not considered to be an inconsistent state. The intended use is to allow “local” overrides until such a time that the main source is updated. Once the main source is updated then all descendants are again set to the same value.
Example scenario 2: A chain exists where a grandparent has a value set which has cascaded correctly down to a child and 2 grandchildren. A user then establishes a parent-child relationship between this parent and another item where the new item is the parent. This new “great-grandparent” has a different set of metadata than the grandparent has. This will cause the new great-grandparent’s set of data to be applied on all descendants.
There will not exist any method to “opt-out” of single cascading metadata changes. The only way to not apply changes made on a parent is to break the parent-child relationship beforehand. As re-establishing that relationship would lead to a full synchronisation of cascading metadata fields, breaking relationships cannot be used for temporary opt-outs. If users want to achieve the functionality of a field that does not cascade down an entire relationship tree they should consider using a separate field that only gets set on the child items.
Cascading metadata does not work within subgroups. There is one exception and that is when subgroups are just to give a header to a section or have ACL applied.
So cascading metadata will work when you have a minimum of 1 occurance and a maximum of 1 occurance and the subgroups are named the same and not referenced. All other cases cascading metadata will not work with subgroups.