I'm using an Views Aggregator Plus table in an attachment above another Views Aggregator Plus table and I'm seeing some weird behaviour.

My Attachment is grouped and compressed on a Field with peoples names and summed on a field with their hours. (It's a computed field, stored in the DB)

My Main table isn't grouped at all, just using Views Aggregator Plus to have sums at the bottom of the Hour column.

For some reason I'm seeing the sums of hours from the attachment replacing values in the main table. One for each person. It's overwriting the value.

A factor that I think may come into play here as well is that I have to use distinct as I am having issues with duplicate rows.

Any thoughts?

Comments

rdeboer’s picture

Hi Drew,

Thanks for your report.

I have no idea of the top of my head how this happens.
I need to get back to my dev set-up, start up the debugger and try and reproduce this issue.

Rik

PS: The DISTINCT should not matter as it is an instruction for the database and Views Aggr Plus does not kick in until after the raw results have been received from the database.

drewmacphee’s picture

Can confirm, distinct indeed has no impact.
http://imgur.com/KPvyrWt

Notice it replaces the first Brad Testerson value (hours) with the total from above.
It's the same for the 2 other users. The first row with their data gets replaced. The others (if their are more than 1) are fine.

drewmacphee’s picture

Has something to do with views_aggregator_render_field
It seems to somehow set the value in both tables.

drewmacphee’s picture

I've found a workaround, but I have no idea why this is happening or why this even works.

It seems when you do:
$entity->{$field_name}[$lang][0][$name] = $raw_value;
it sets the value on the main table, but you still need to do:
$row->{'field_' . $field_name} = $views_field_handler->set_items($row, $row_num);
to set it on the table you're actually working on.
So I just grab the old value and replace it after:

  if (isset($raw_value)) {
    // Only supporting values of 1 item, at index 0.
    if (is_array($raw_value)) {
      $entity->{$field_name}[$lang][0] = $raw_value;
    }
    elseif (!empty($entity->{$field_name}[$lang][0])) {
	$old_value;
      foreach ($entity->{$field_name}[$lang][0] as $name => $value) {
        if ($name != 'value' && !($name == 'tid' && is_numeric($raw_value))) {
          return isset($row_num) ? FALSE : (isset($raw_value) ? $raw_value : $value);
        }
        // The tid may be set in case of min, max, most frequent etc.
		$old_value = $value;
        $entity->{$field_name}[$lang][0][$name] = $raw_value;
      }
    }
	
    if (isset($row_num)) {
      // Next employ set_items() to re-render the $entity updated above,
      // placing both the 'raw' and 'rendered' versions in field_...[].
      $row->{'field_' . $field_name} = $views_field_handler->set_items($row, $row_num);
	  $entity->{$field_name}[$lang][0]['value'] = $old_value;
      // The final step is to theme the rendered values.
      // An alternative for the line below is:
      // return $views_field_handler->advanced_render($row);
      return $views_field_handler->theme($row);
    }
  }
rdeboer’s picture

Great work Drew!

Yes Views works in mysterious ways doesn't it!

Thanks for the patch! What would be hugely helpful is a "read" patch created using the diff command so we can clearly see what exactly was changed, in which file and line number.

Other than that -- very nicely done!
Hope to implement this soon.

Rik

rdeboer’s picture

While the intracacies and consequences of this patch are somewhat unclear like they're to you Drew, I've committed to the repository a version of your patch with attribution. Your second on drupal.org!
Let's monitor how it holds up in 7.x-1.x-dev.
Rik

rdeboer’s picture

Assigned: Unassigned » rdeboer
Status: Active » Fixed
drewmacphee’s picture

Oh thanks, I was just about to make a proper one.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.