Workflow: Previous time views field results in duplicate nodes
jdleonard - April 7, 2009 - 20:59
| Project: | Workflow |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
I'm running into problems with the "Workflow: Previous time" views field. When enabled, the field results in duplicate nodes in the view, each duplicate having a different time (each corresponding to one time when the workflow state was changed). I feel like this field should just result in one of each node and that it should have just the most recent time that the state changed.
#1
Yes, I run into this too. I already tried several ways to get rid of this (as a grouping the query by nids) but with current implementation of views and WF it's impossible to solve this issue. We need to link up workflow_node and workflow_node_history tables by adding hid column to workflow_node. After this, proper joins can be build in views.
#2
Im having same issue. Is there a fix???
#3
subscribing.
#4
So, I'm a Drupal newb, but not a stranger to coding. I've written a couple patches, but never worked with the Views2 API. I'm getting bitten by this bug, and here's my thoughts -- I'd love for someone to comment on them.
I think the core problem here is that the 'previous time' and 'previous comment' fields are doing what they're supposed to. The scheduled fields work too, but if we have previous and scheduled, what's missing? Current, of course -- we need a 'current comment' and a 'current time' option. We can use table aliasing in views2 for this I think:
<?php
$data['workflow_node_current']['table']['group'] = t('Workflow');
// Explain how this table joins to others.
$data['workflow_node_current']['table']['join'] = array(
'node' => array(
'table' => 'workflow_node_history',
'field' => 'nid',
'left_table' => 'node',
'left_field' => 'nid',
),
);
// time
$data['workflow_node_current']['stamp'] = array(
'title' => t('current time'), // appears in views ui.
'help' => t('the time at which the node moved from the last state to the current state.'),
'field' => array(
'handler' => 'workflow_views_handler_field_current_date',
'click sortable' => true,
),
'filter' => array(
'handler' => 'workflow_views_handler_filter_current_date',
'numeric' => true,
),
'sort' => array(
'handler' => 'workflow_views_handler_sort_current_date',
),
);
// comment
$data['workflow_node_current']['comment'] = array(
'title' => t('current comment'), // Appears in views UI.
'help' => t('The comment describing why the node was moved from the last state to the current state.'),
'field' => array(
'handler' => 'workflow_views_handler_field_current_xss',
'click sortable' => TRUE,
),
'filter' => array(
'handler' => 'workflow_views_handler_filter_current_string',
'numeric' => TRUE,
),
);
?>
Where I'm stuck at, is the use of a custom handler to add a 'MAX(stamp)' to the query. I've seen references to doing a
<?php$this->query->add_field(NULL, "MAX(SOME_FIELD)");
?>
If no one else can help, I can muddle through it with dpr() and get it figured out, but I'd love a little guidance here.
#5
Well, here's my first crack at it, and it works for me.
I created a table alias, and use a sub select (yuck) on the join to ensure only the most recent entry is returned. This adds two fields/filters/sort options: "Current time" and "Current comment".
I'm still very open to better ways to do this, but this method does appear to work.
#6
#7
Thanks for patching, justintime. I tested it out and it seems to work fine.
I'm also of the opinion that the code could be a bit cleaner; that subquery raises some red flags for me too. I poked at it for a while and couldn't come up with anything better though.
Also, your patch includes some extraneous code at the top. It changes some strings and Boolean values to lowercase, which does not comply with Drupal coding standards. So you may want to have a look at that.