EntityTokens - Normalize data-loading via `myEntityId` (eg `activityId`)

Before
======

EntityTokens has two protocols for fetching data:

1. For scheduled-reminders, hook into the main query. Add N-ary columns to select
   any fields used by tokens.
2. For everything else, expect a parameter `$row->context['activityId']`. Collect
   the `activityId`s and fetch the needful via APIv4.

This poses a few challenges, but TLDR it's duplicate functionality.  That
means that listeners who consume the `activityId` must check multiple
places.  It means that the data-loading could return slightly different data
(ie based on SQL query vs API data-loader).

After
=====

* EntityTokens has one protocol for fetching data: it must receive `activityId`s and then
  call APIv4 for the batch.
* For scheduled-reminders, EntityTokens uses a small adapter to ensure that `activityId`s
  are available.

diff --git a/CRM/Core/EntityTokens.php b/CRM/Core/EntityTokens.php
index c1cb2fcbc414ac69a8eed4aa3b8981d5cea2a0f3..c9ff0128cd9a21cc7b09062e41d0ce5264b0ef4a 100644 (file)
--- a/CRM/Core/EntityTokens.php
+++ b/CRM/Core/EntityTokens.php
@@ -349,9 +349,7 @@ class CRM_Core_EntityTokens extends AbstractTokenSubscriber {
     if ($e->mapping->getEntity() !== $this->getExtendableTableName()) {
       return;
     }
-    foreach ($this->getReturnFields() as $token) {
-      $e->query->select('e.' . $token . ' AS ' . $this->getEntityAlias() . $token);
-    }
+    $e->query->select('e.id AS tokenContext_' . $this->getEntityIDField());
   }
 
   /**