Often I get a log message that Rules action is unable to modify certain data because it is "unable to set the data property value as the parent data structure is not set."
What exactly is "parent data" or "parent data structure"?
Simple use case. Condition: entity (referred node) has a "ref_data_field"
Action:
- data from "ref_data_field" is processed, giving the output "processed_data_added" or "processed_data_variable_added"
- set a data value: node:field_to_fill = "processed_data_added" (or "processed_data_variable_added")
- save a node
Sometimes such an action isn't fulfilled because "parent data structure is not set."
I have been looking what is the difference between successful and unsuccessful action and was not able to catch the clue. Also didn't find it in documentation.
Most often I have this problem when computing date/time. Testing messages display values properly but values are not set.
Comments
Comment #1
AndrzejG commentedI found that a destination field has to have default value. The condition of empty field is not enough.
I think it is not proper behaviour as it imposes certain functionality limitations.
Comment #2
AndrzejG commented#1 is not true. There are a lot of inconsistencies.
Comment #3
smscotten commentedNot an answer, but may shed a little light on the issue. I encountered this message when I mistakenly created a rule to alter node:source:title instead of node:title.
Comment #4
mitchell commentedLet's definitely create a documentation page for this once the materials are put together.
Comment #5
kbk commentedI run into this problem when trying to compare values from a referenced node. I'm assuming "parent structure" means the referenced node is not loaded and therefore its fields are not available.
Comment #6
mitchell commentedAfter thinking about these three scenarios where the 'parent data structure' error occurs (entity references, date/time, and node:title vs node:source:title) and studying the API more closely, I'm 95% sure that it occurs when values exposed by parent elements, in property chains, are not of the data type that the error-ing plugin requires (more?). I believe that conditions which expose values, which are used by actions deeper in the configuration, are parents to these nested elements, and if they are misconfigured, then the child action cannot execute. So, obviously, it's necessary to correctly expose actionable data ( / properties?); and instead of asking fago for a better error message, I think we should address this in these documentation pages:
* The Data availability page's section on 'Loading data values' includes, "The values on an entity identified in an Entity Reference field can be loaded [using "Fetch entity by id" and "Fetch entity by property" actions].
A referenced entity is referred to as a "Parent data structure"." I think this section, overall, needs a lot of work: better content & better organization. There are 3 actions, 1 additionally referenced module, and 1 API reference all overloaded and under-described in 2 short paragraphs. Any takers? :)* The Setting data values page has a guide on populating values related by an entity reference field, so we should coordinate the info on these two pages to alleviate this confusion about how to navigate and operate on related data. I think including more use cases of how "Set a data value" can be used would be most beneficial, so perhaps an intro paragraph with a primer on Data availability would provide the framework for the range of use cases to cover. This is mostly cleanup work and also content we can all contribute to.
* The Data selection ( / input?) page's description of how to use the data selector says, "If selecting an item ending with ':' you can access data inside that object, creating chains of related data." I think I ran across an article describing nested data objects and the 'placeholder numbers' for objects in 'unfilled lists', maybe in one of the Commerce guides, but I can't find it atm. Identifying the correct data seems especially relevant to the node:title vs node:source:title scenario. Overall, it would also be a good place to further clarify how these drill-down (inside?) objects work, how they are listed, and why one value is correct while another is incorrect.
* The Glossary now has a definition for elements to help clarify some of this. It's not a UI exposed concept, but at least in this case, it's useful info. (
<tangent>It may actually make sense to use the 'elements' term in the UI if we "collapse conditions and actions in the same expression tree" as a few users have recently suggested. There's more info about that in the 'Conditionals' issues.</tangent>)(btw, it's not very obvious, but docs pages are editable by everyone.)