When you add a new field "Last state change" to your view, you get a broken handler. It happens because when the module implements hook_views_data, it uses handlers names definned into a hook_views_handlers function, which is deprecated for Drupal 7.

hook_views_data defines the field "Last state change" like this:

// Last State change.
  $data['support_ticket']['last_state_change'] = array(
    'title' => t('Last state change'),
    'help' => t('Date of last state change.'),
    'field' => array(
      'handler' => 'support_views_handler_field_last_state_change',
      'click sortable' => TRUE,
      'sort' => array(
        'handler' => 'views_handler_sort',
      ),
    ),
  );

And later, in hook_views_handlers it does:

/**
 * Implements hook_views_handlers().
 */
function support_views_views_handlers() {
  return array(
    'info' => array(
      'path' => drupal_get_path('module', 'support_views'),
    ),
    'handlers' => array(
      'views_handler_filter_support_state' => array(
        'parent' => 'views_handler_filter_in_operator',
      ),
      'views_handler_filter_support_client' => array(
        'parent' => 'views_handler_filter_in_operator',
      ),
      'views_handler_filter_support_priority' => array(
        'parent' => 'views_handler_filter_in_operator',
      ),
      'support_views_handler_field_last_state_change' => array(
        'parent' => 'views_handler_field_date',
      ),
    ),
  );
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

diego21’s picture

Here is a simple patch for that problem, just apply the patch and clear caches.

diego21’s picture

Status: Active » Needs review
dawehner’s picture

+++ b/sites/all/modules/support_views/support_views.views.inc
@@ -158,7 +158,7 @@ function support_views_data() {
-      'handler' => 'views_handler_filter_support_state',
+      'handler' => 'views_handler_filter_in_operator',
     ),

@@ -204,7 +204,7 @@ function support_views_data() {
-      'handler' => 'views_handler_filter_support_client',
+      'handler' => 'views_handler_filter_in_operator',

@@ -237,7 +237,7 @@ function support_views_data() {
-      'handler' => 'views_handler_filter_support_priority',
+      'handler' => 'views_handler_filter_in_operator',

... these handlers still all exists, so they actually would not have to be replaced ....

diego21’s picture

You're right, thanks! Besides, it returns this error after change the handler of last_state_change field to views_handler_field_date

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'support_ticket.last_state_change' in 'field list'

diego21’s picture

I created a .install file to update the support_ticket database schema:

/**
 * @file
 * Contains install and update functions for Support Views.
 */


/**
 * Adds a missing field to support schema.
 */
function support_views_update_7000() {
  
  // A new field for the last state change.
  $new_field = array(
    'description' => 'The Unix timestamp when the support_ticket was most recently saved.',
    'type' => 'int',
    'not null' => TRUE,
    'default' => 0,
  );

  db_add_field('support_ticket', 'last_state_change', $new_field);
  
  // A new index for this field.
  db_add_index('support_ticket', 'support_ticket_last_change', array('last_state_change'));
  
}


Then, I implemented hook_node_update to add the last_state_changed info when the ticket is updated. But when a new ticket is created, last_state_changed keeps emty, is that ok? Should I consider that to? Technically when the ticket is create, its state isn't uptaded.

I also updated the patch file.

diego21’s picture

Added changes and new file to a single .patch file.

diego21’s picture

Fixed trailing whitespaces errors and new blank line at EOF error.

dawehner’s picture

I'm sorry, but you should rather fix the handler than updating a table of a different module.

diego21’s picture

But it's nothing wrong with the handler, it's the Views' date handler. I updated that table because support_views module is supported on that module (support), and the timestamp needed by the field last_state_change must be stored in somewhere (at least is what I think).
All other fields implemented in the module are defined in support's schema. Maybe this module would needs its own table, but I think that's not the best approach, right? I mean, a module developed to connect other module with Views shouldn't store extra info.

Thanks for your comments! :D