I'm using the field collections module which provides a 'host-entity' chain. When I use the data selector input method, the chained tokens work but not when in direct input mode. I assumed this would work since there's this message

Note that token replacements containing chained objects – such as [node:author:uid] – are not listed here, but are still available. The data selection input mode may help you find more complex replacement patterns.

example:
item:host-entity:mail works in data selection mode.
[item:host-entity:mail] does not work in direct input mode.

Is this supposed to work. Could it be a problem with field-collections? How would I find out?

Comments

ErnestoJaboneta’s picture

Issue summary: View changes

clarification

arbel’s picture

Component: Rules Core » Rules Engine

Same issue for me.

arbel’s picture

anyone?

willito’s picture

I have the same exact issue. Chained tokens do not work in direct input mode, but function as expected in data selection mode. I am also using field-collections.

ksouthworth’s picture

I also have this exact same issue

brandy.brown’s picture

i am not using field collections, but I have this same problem.

nmc’s picture

Category: support » bug

I'm not using field collections but have the same problem whereby tokens work when in Data Selection mode but not in direct input mode.

I think this is the same issue: #1475946: How to access tokens from fetched entity fields?

fago’s picture

Status: Active » Fixed

If you have problems with that please try updating to the entity api dev version. If this doesn't help please re-open and provide more details on the not working tokens.

nmc’s picture

I tested using the entity api dev version. Some of the tokens that were previously working stopped working and the tokens that were not working started to work.

Will test more thoroughly and provide more details later.

nmc’s picture

Status: Fixed » Active

The following are custom fields (textfields) in the user account (admin/config/people/accounts/fields):

[commerce-order:owner:field-user-business-name] <-- worked previously, STILL works
[commerce-order:owner:field-user-contact-name] <-- worked previously, STILL works
[commerce-order:owner:field-user-phone] <-- worked previously, STOPPED working
[commerce-order:owner:field-user-fax] <-- worked previously, STOPPED working

The following are from the addressfield fields in the user account (admin/config/people/accounts/fields). These were the fields that were NOT working previously but are now working.

[commerce-order:owner:field-user-billing-address:thoroughfare]
[commerce-order:owner:field-user-billing-address:premise]
[commerce-order:owner:field-user-billing-address:locality]
[commerce-order:owner:field-user-billing-address:administrative-area]
[commerce-order:owner:field-user-billing-address:postal-code]
[commerce-order:owner:field-user-billing-address:country]

There are fields in the commerce order entity and were working previously. They have since STOPPED working.

[commerce-order:field-order-po-number]
[commerce-order:field-order-notes]

I can't see any patterns above especially given that some textfields in the user account work and some dont. Happy to continue testing or provide more detailed feedback if it would help. Let me know.

nmc’s picture

Further testing reveals that the fields that done work are fields that are empty. But instead of showing blank, the token gets printed. So where I would expect to see the PO Number or nothing at all if customer left the field blank, I see "[commerce-order:field-order-notes]"

My issue can be fixed by adding $replacements += array_fill_keys($tokens, ''); in the evaluate function, on after line 178 in rules/modules/system.eval.inc

Or if I'm following core's token_replace function then it should be:

    if (!empty($options['clear'])) {
      $replacements += array_fill_keys($tokens, '');
    }

But then you I would have to set $options['clear']

I'm happy to contribute a patch but I'm not certain this is the right solution for everyone.

mitchell’s picture

Priority: Normal » Major
Status: Active » Needs review

Nice job investigating this, nmc. If its not too much trouble to roll a patch for others to test, that may help fago save time.

brandy.brown’s picture

I switched to the dev version of entity and still have no replacement patterns on direct input.

bobslee’s picture

Does this somehow relate to issue?
See that thread... I experienced that Entity-RC2 broke some working token replacements with Entity-RC1.

star-szr’s picture

Status: Needs review » Active

@nmc - A patch would be great, although it sounds like the patch may not address the original reported issue. Can you confirm or deny?

Setting back to active since there is no patch yet.

star-szr’s picture

Issue summary: View changes

clarification