[PP-1] Base fields miss out on Views data from hook_field_views_data()

#2548395: Provide views relationships for DER base fields is also related here.

I think it's at least a major.

Dang, this just bit me.

Anyone know if there's a workaround for this, perhaps something I can use in a custom module just to tell views to use the proper views filter plugin for datetime base fields?

The existing Drupal\datetime\Plugin\views\filter\Date filter plugin uses Drupal\views\FieldAPIHandlerTrait to determine if the underlying field storage definition is configured as a "date" or a "datetime" element. I think this needs to be refactored before the filter could be used for base field definitions.

Nevermind, this base field definitions work just fine, I just had an error elsewhere that led me to thing otherwise

Is there a workaround about this so views can use datetime exposed filter as date ?

@Dom. you can implement hook_views_data the basefield for now just like http://cgit.drupalcode.org/dynamic_entity_reference/tree/tests/modules/d....

Postpone on #2337515: Allow @FieldType to customize views data.

@jibran, could you explain what should be put in views data ?
I'm trying to use the calendar module with a datetime field defined in a custom entity.
I manage to create the calendar template by creating this views data :

namespace Drupal\kaukis_tests\Entity;
use Drupal\views\EntityViewsData;

class TestEntityViewsData extends EntityViewsData {
  public function getViewsData() {
    $additionalData = [
      'test_date' => [
        'title' => new TranslatableMarkup('Birth date'),
        'help' => new TranslatableMarkup('Birth date'),
        'field' => [ 'id' => 'field' ],
        'argument' => [ 'id' => 'date' ],
        'filter' => [ 'id' => 'date' ],
        'sort' => [ 'id' => 'date' ],
        'entity field' => 'test_date',
      ]
    ];
    $data['test_field_entity_field_data'] = array_merge($data['test_field_entity_field_data'], $additionalData);
    return $data;
  }
}

However the calendar is not working and I get this error :

\Drupal\calendar\Plugin\views\style\CalendarStyle: A calendar date argument is required when using the calendar style, but it is missing or is not using the default date.

So it make me think my views data is not well defined.

@grubshka_v2 i am also trying to get this working. I guess this is the starting point:

<?php
function datetime_range_field_views_data(FieldStorageConfigInterface $field_storage) {
  \Drupal::moduleHandler()->loadInclude('datetime', 'inc', 'datetime.views');

  // Get datetime field data for value and end_value.
  $data = datetime_type_field_views_data($field_storage, [], 'value');
  $data = datetime_type_field_views_data($field_storage, $data, 'end_value');

  return $data;
}
?>

The problem is that this is for FieldStorageConfig fields, not for base fields. Right now i am also trying to build the array on my own, but without success so far... Does anyone know a module that uses a datetime base field and exposes it for views?

Ok, I managed to solve this for my entity type:

<?php
$data['event_registration_time_slot']['daterange__value']['filter'] = [
      'field' => 'daterange__value',
      'table' => 'event_registration_time_slot',
      'id' => 'datetime',
      'field_name' => 'daterange',
      'entity_type' => 'event_registration_time_slot',
      'allow empty' => TRUE,
    ];
    $data['event_registration_time_slot']['daterange__value']['sort'] = [
      'field' => 'daterange__value',
      'table' => 'event_registration_time_slot',
      'id' => 'datetime',
      'field_name' => 'daterange',
      'entity_type' => 'event_registration_time_slot',
    ];
?>

This goes into the getViewsData() method of the views_data handler of the entity.

A workaround for it could be to use a contextual filter as query parameter and in the views exposed form alter to add a select with the same query parameter as an exposed filter. For more details see here: http://drupalsun.com/fabrice/2017/10/19/filter-content-year-views-drupal-8

I have tried to do #13 and can't get the getViewsData() routine to run, I have tried everything. I have a custom entity and the stub files for this entity were created by Drupal console. The function getViewsData() is not being called at all.

class TimeOffDayViewsData extends EntityViewsData {

  /**
   * {@inheritdoc}
   */
  public function getViewsData() {
    $data = parent::getViewsData();

    // Additional information for Views integration, such as table joins, can be
    // put here.

    $data['TimeOffDay']['timeoffdate']['filter'] = [
      'field' => 'timeoffdate',
      'table' => 'TimeOffDay',
      'id' => 'datetime',
      'field_name' => 'daterange',
      'entity_type' => 'TimeOffDay',
      'allow empty' => TRUE,
    ];

    return $data;
  }

}

This was super tricky, I managed to get some basic integration for a datetime range field using the following snippet in my custom views data handler, where date_time was the name of by base field:

  /**
   * {@inheritdoc}
   */
  public function getViewsData() {
    $data = parent::getViewsData();
    $this->attachDateTimeViewsData($data);
    return $data;
  }

  /**
   * Fix views data integration for the datetime field.
   */
  protected function attachDateTimeViewsData(&$data) {
    // Automatic integration blocked behind https://www.drupal.org/node/2489476.
    $datetime_columns = [
      'date_time__value',
      'date_time__end_value',
    ];
    foreach ($data as $table_name => $table_data) {
      foreach ($datetime_columns as $datetime_column_name) {
        $data[$table_name][$datetime_column_name]['filter']['id'] = 'datetime';
        $data[$table_name][$datetime_column_name]['filter']['field_name'] = 'date_time';
        $data[$table_name][$datetime_column_name]['argument']['id'] = 'datetime';
        $data[$table_name][$datetime_column_name]['argument']['field_name'] = 'date_time';
        $data[$table_name][$datetime_column_name]['sort']['id'] = 'datetime';
        $data[$table_name][$datetime_column_name]['sort']['field_name'] = 'date_time';
      }
    }
  }

Would #2930736: EntityViewsData assumes BaseFieldDefinitions where it should use FieldDefinitionInterface help at all with this?

If #2337515: Allow @FieldType to customize views data doesn't look like it will land in time for Drupal 9, we should take advantage of the BC break, and change hook_field_views_data()'s parameter to be a FieldStorageDefinitionInterface. We could then invoke it from EntityViewsData with base fields.

Also, taking the title from #2903770: Base fields miss out on Views data from hook_field_views_data() which was closed as a duplicate, which is MUCH clearer and explains the wider problem.

> If #2337515: Allow @FieldType to customize views data doesn't look like it will land in time for Drupal 9

Why not? What the issue requires is someone dedicating some time to it and getting it started, it should not be that complicated.

> we should take advantage of the BC break, and change hook_field_views_data()'s parameter to be a FieldStorageDefinitionInterface.

There is no BC break with D9, the idea is that the only thing we do between 8.9 and 9.0 is remove *already* deprecated code, so that modules can be compatible with both versions at the same time. That's not possible with a type hint change like that, which is why we need a new way to integrate that.

> There is no BC break with D9

I know that's what's been announced, but I don't buy it. We need to *sometimes* be able to break BC. There are some things that aren't possible without a BC break.

PP

As it looks like it is difficult to land, I propose to create an help topic on how to integrate some most used base fields type into views.
This will ease the entity creation for a lot of people.

This is probably soft-blocked on #3116481: Convert EntityViewsDataTest from a unit test to a kernel test like a lot of things to do with Views Data.

Don't you think we need a clear documentation for developers without experiences in views in order to help them to create entities with base fields integrated in views?

This is a 6 year old thread... maybe we will wait one or two years...

Yes, of course, we need docs for workarounds. I meant that the fix is blocked by the tests, not the documentation. Sorry for the confusion!

thank you, I have added the first example with a datetime field, but I am stuck on how to override properly EntityViewsData
Any help appreciated
https://www.drupal.org/project/drupal/issues/3213021#comment-14097782

Hi,

Notes that may light somebody.

I found why the default type is string to datetime basefields. In web/core/modules/views/views.views.inc we have a switch that set it how string:

// Expose data for each field property individually.
  foreach ($field_columns as $column => $attributes) {
    $allow_sort = TRUE;

    // Identify likely filters and arguments for each column based on field type.
    switch ($attributes['type']) {
      case 'int':
      case 'mediumint':
      case 'tinyint':
      case 'bigint':
      case 'serial':
      case 'numeric':
      case 'float':
        $filter = 'numeric';
        $argument = 'numeric';
        $sort = 'standard';
        if ($field_storage->getType() == 'boolean') {
          $filter = 'boolean';
        }
        break;

      case 'blob':
        // It does not make sense to sort by blob.
        $allow_sort = FALSE;
      default:
        $filter = 'string';
        $argument = 'string';
        $sort = 'standard';
        break;
    }
...

The datetime field type must not have a valid filter handler defined.

In datetime_type_field_views_data_helper(), in datetime core module, we have a comment that say:

// @todo This code only covers configurable fields, handle base table fields
// in https://www.drupal.org/node/2489476.

I think that the problem is the base fields don't have Field Storage.

If I execute:

$fieldStorage = \Drupal::entityTypeManager()
      ->getStorage('field_storage_config');
    $fields = $fieldStorage->loadMultiple();

$fields don't have any base fields.

I fix my custom entity fields filters with two hooks:

/**
 * Implementa hook_views_data_alter().
 */
function hook_views_data_alter(array &$data) {
  if (isset($data["payment_installment"]["due_date"])) {
    $installmentsBaseFields = \Drupal::service('entity_field.manager')
      ->getFieldStorageDefinitions('payment_installment');
    /** @var \Drupal\Core\Field\BaseFieldDefinition $field */
    foreach ($installmentsBaseFields as $field) {
      $fieldType = $field->getType();
      if ($field->isBaseField() && 'datetime' === $fieldType) {
        $data["payment_installment"]["due_date"]["argument"]["id"] = 'date';
        $data["payment_installment"]["due_date"]["filter"]["id"] = 'date';
      }
    }
  }
}

/**
 * Implementa hook_views_query_alter().
 */
function hook_views_query_alter(ViewExecutable $view, QueryPluginBase $query) {
  if ($view->id() == 'plazos_sin_id') {
    // UNIX_TIMESTAMP(payment_installment.due_date) BETWEEN 1737154800 AND 1737327600
    if (isset($query->where[1]["conditions"])) {
      foreach ($query->where[1]["conditions"] as &$condition) {
        if (str_starts_with($condition['field'], 'payment_installment.due_date')) {
          $condition['field'] = str_replace(
            'payment_installment.due_date',
            'UNIX_TIMESTAMP(payment_installment.due_date)',
            $condition['field']
          );
        }
      }
    }
  }
}

I realize the status of this is postponed, but the fix for issue as I understand it seemed doable so I opened a MR.

This is what I think the goal of this issue is (correct me if I'm wrong):

If you have a base table (in Drupal speak, apparently this means a table unrelated to any entity) that has a datetime field/column, it should be filterable in views the same way that a timestamp integer field would be. Additionally the datetime field should be displayed in the view the same way that a timestamp field can be displayed.

If that's correct, then the MR does the trick for me.

For example, given this:

/**
 * Implements hook_schema().
 */
function my_module_schema() {
  $schema['my_custom_table'] = [
    'description' => 'A custom table.',
    'fields' => [
      'date' => [
        'type' => 'varchar',
        'mysql_type' => 'datetime',
        'not null' => TRUE,
      ],
    ],
  ];

  return $schema;
}

/**
 * Implements hook_views_data().
 */
function my_module_views_data() {
  // Make my_custom_table table
  // queryable by views.
  $data['my_custom_table'] = [
    'table' => [
      'group' => t('A group'),
      'provider' => t('my_module'),
      'base' => [
        'field' => 'date',
        'title' => 'An example table',
        'help' => 'This is an example table description.'
      ],
    ],
    'date' => [
      'title' => t('A datetime field/column'),
      'help' => t('This is a datetime field/column.'),
      'field' => [
        // ID of field handler plugin to use.
        'id' => 'datetime',
      ],
      'sort' => [
        // ID of sort handler plugin to use.
        'id' => 'datetime',
      ],
      'filter' => [
        // ID of filter handler plugin to use.
        'id' => 'datetime',
      ],
      'argument' => [
        // ID of argument handler plugin to use.
        'id' => 'datetime',
      ],
    ],
  ];
}

I can make a view of "An example table", and add a "A datetime field/column" field and filter.

> If you have a base table (in Drupal speak, apparently this means a table unrelated to any entity)

That is not what base table means. Base table and base field specifically refers to entity base fields to goal is to have them declared automatically viewing any manual views data hooks.

Ah perhaps I'm in the wrong place then. I'll open a different issue. The problem I'm trying to solve is:
1. Views does not support filtering on a datetime database field.
2. Views does not support displaying a datetime database field.