Problem/Motivation
From #2543726: Make $term->parent behave like any other entity reference field:
It seems to be a generic problem with views data generated for multi-value based fields. The code is assuming that if it only have one property/column it should just use the field name, which in this case was 'parent' but this field is multi-value, so it has a dedicated table, which means the actual schema column name should be used. I think it's correct to always use this as regular base fields will have the same result as the actual $field_name we were using before. So we basically just remove the $multiple logic. So it kind of worked by chance before, because field names and storage names were always the same. As a side note, configurable fields are not affected as they are handled slightly differently in views_views_data().
Example breakage from the above issue:
- Base field is create with name 'parent', and it's a multi-value field - this means it gets it's own storage table, 'taxonomy_term__parent'
- This table does not have the same format as base fields in the base table, so 'parent' would not be named in a single column 'parent', the actual value field is 'parent_target_id' - similar to any other configurable field
- When the views data is generated, it assumes the field name due to this code:
$multiple = (count($field_column_mapping) > 1);
$first = TRUE;
foreach ($field_column_mapping as $field_column_name => $schema_field_name) {
$views_field_name = ($multiple) ? $field_name . '__' . $field_column_name : $field_name;
$table_data[$views_field_name] = $this->mapSingleFieldViewsData($table, $field_name, $field_definition_type, $field_column_name, $field_schema['columns'][$field_column_name]['type'], $first, $field_definition);
$table_data[$views_field_name]['entity field'] = $field_name;
$first = FALSE;
}So the wrong assumption is that any field that only has one column in the mapping must have the same column name as the field name itself! Which is not a correct assumption. This is only TRUE (and because the storage implementation happens to use the same names) for base fields that share a table.
Another side affect of this, the Views UI contains two handler entries for each of these fields, one working implementation and one broken one, for things like user roles. Only because UserViewsData is explicitly creating the 'roles_target_id' item itself, to basically get around this bug. Some of this data is just wrong, it doesn't work, and it should be be there.
Proposed resolution
Use the schema field name, as it already generates the correct field name. Still use the field name for the 'entity field' value. The tests need to be fixed as they expect the wrong values in some assertions.
Remaining tasks
User interface changes
Some duplicate handlers will be removed in the Views UI listing