Open simonerd opened 5 months ago
Have you seen https://github.com/statamic/cms/pull/9385?
Have you seen statamic/cms#9385?
Yes I had seen it, but actually forgot about it (fun fact: it was opened by one of my team members 🙈😄). Anyway, the approach in https://github.com/statamic/cms/pull/9385 only covers the "parent" case, while the approach of passing on the complete field path would allow for more than just one level up.
I mean, there would be nothing wrong with adding both if you'd ask me. The parent
keyword would be more accessible and usable for simple field conditions, while adding the field path would extend the possibilities of custom functions.
Consider this blueprint situation:
root
keyword) (see here)This is clearly a case for a custom condition function. However, so far custom condition functions get the following parameters:
params
,target
,targetHandle
,values
,root
,store
,storeName
, which still does not give any indication on where the current field would be in a nested structure.Looking into the code it should be possible to pass on the field path (so the information as to where the currently observed field is) to a custom condition function, so I could add my own logic and consider every (upwards) relation. For the example above that would be
pagebuilder.0.nested_replicator.0.inner_text_field
. Using the store or theroot
object, this would allow me to access whatever level I would like to consider.