support label callback for the autocomplete search (as opposed to just on render-time)

Hi @derikson, thanks for opening this.

It looks like we should add support for this, indeed! I think I'll be able to pick it up later this week and get it on the next release. Thanks!

The issue seems outdated to me, because everywhere in the module we're using the entity_label() function to calculate the label of entity.

I'm unsure of what we can do here, but I'm open to suggestions if we can do something to get this feature added.

If there isn't a 'label' column for the entity type, the system will fall back to the 'id' column for searching, so an entity could be referenced by entering it's ID, and the actual label should be returned in the results for the user to select (as provided by the 'label callback' function).

Validation poses another problem, as not having anything to search against in the db, means we can mostly check just entity ID. Can see a few possible ways, but both involving either adding a new custom hook for this, and any case new logic to filter out returned entities after calling their 'label callback', to see if they should be returned as results or not.

Need to think a bit more about it, and see whether that'd fit a possible 2.x release instead of putting it in 1.x, as it means tinkering quite a bit in both the validation and autocomplete callbacks, but in any case, ideas welcome.

Hi,

I'm going to close this, just to avoid any expectations of it getting implemented. I'm not opposed to getting some support for it if someone decides to contribute it, but I don't plan to add it myself because:

1.- Seems a very extreme use case caused by a non-standard definition of entities from the mailchimp module (I might be wrong here, don't know enough details of the actual implementation in the mailchimp module).

2.- I don't think this module should go into adding complex logic with caching to allow searching in "virtual" fields created on the fly. A better solution would be to alter the entities created by mailchimp so that they have an actual label column to search on if you can't rely just on the entity ID.

Alternatively, Search API makes way more sense for your use case, so perhaps you could have a form element type to simply search in a search api index that already stores the label you need as an aggregated field. All the logic for aggregation and searching exists in that module already, and I don't see any reason to have something custom in this module.

Feel free to reopen. Thanks!

I just implemented same functionality for eck entity in custom module, here is an example.

function HOOK_eck_entity_clients_logos_label(&$entity, $entity_id) {
  if (!empty($entity->field_title[LANGUAGE_NONE][0]['safe_value'])) {
    return $entity->field_title[LANGUAGE_NONE][0]['safe_value'];
  } else {
    return $entity_id;
  }
}


/**
 * Implements hook_entity_query_alter().
 */
function HOOK_entity_query_alter(EntityFieldQuery $query) {
  $entity_type = $query->entityConditions['entity_type']['value'];
  $entity_bundle = $query->entityConditions['bundle']['value'][0];
  $string = $query->metaData['era_search_string'];

  if (
    in_array('era_query', $query->tags) &&
    $entity_type == 'clients' &&
    $entity_bundle == 'logos'
  ) {
    $conditions = &$query->propertyConditions;

    foreach ($conditions as $key => $condition) {
      if($condition['column'] == 'id') {
        unset($conditions[$key]);
      }
    }

    $query->fieldCondition('field_subtitle', 'value', $string, 'CONTAINS');
  }
  return;
}