Inaccurate Position -> Total being passed to action with Views 3.8

Found this issue as well, when using VBO's file archive action against multi-page views.

For multi-page views, $views->total_rows resets per page as the batch operation runs, so it doesn't represent the total rows in the batch - just the total rows for the current page of the view. This is true of older versions of views 7.x as well.

I found this while using the archive action in VBO - the archive itself would succeed, and the file would write itself to the file system, but not put the message 'An archive has been created and can be downloaded from ...' on the screen. That made the archive action pretty unusable, as you could imagine.

The logic testing completion of the batch in archive.action.inc relied on that faulty value of $views->total_rows, stored in $context['progress']['total;'] and tested before providing the download link to the user - see archive.action.inc:66.

  // The operation is complete, create a file entity and provide a download
  // link to the user.
  if ($context['progress']['current'] == $context['progress']['total']) {
    $archive_file = new stdClass();
    $archive_file->uri      = $destination;
    $archive_file->filename = basename($destination);
    $archive_file->filemime = file_get_mimetype($destination);
    $archive_file->uid      = $user->uid;
    $archive_file->status   = $context['settings']['temporary'] ? FALSE : FILE_STATUS_PERMANENT;
    file_save($archive_file);

    $url = file_create_url($archive_file->uri);
    $url = l($url, $url, array('absolute' => TRUE));
    _views_bulk_operations_log(t('An archive has been created and can be downloaded from: !url', array('!url' => $url)));
  }

That code won't run without the proper value set into $context['progress']['total'] which gets originally set in views_bulk_operations_adjust_selection(). Thus, the download link never ends up being printed to the screen.

With the patch applied, the archive ran as expected and the download link displayed. Looks like this patch works just fine to resolve my issue.

I'm setting to RTBC - should this issue be retitled to make it easier to find? There might be others out there wondering why some behavior fails on mult-page VBOs, but aren't so deep into the code as to know that $views->total_rows was the culprit.

It looks like this is the only action in vbo that relies on $context['progress']['total'], so the effects of this bug might be limited to the archive action only...thoughts?

Committed, thanks.

I am using Acquia Dev Desktop on my Win 7 machine.

I found the instructions ambiguous.

Here's what I did that worked.

Created a libraries folder (where "Sam" is my Win logon ID): C:\Users\Sam\Sites\devdesktop\openoutreach-7.x-1.19\sites\all\libraries. I then unzipped libraries-7.x-2.2.zip and copied the contents to the libraries folder. (You have to drill down to get the contents of libraries from the zip file.) I also created a mailchimp folder inside the libraries folder. I then copied the contents of the mailchimp-mailchimp-api-php-7ac99b5ac746.zip file to the mailchimp folder. I then flushed all caches.