NOTE: This starts out sounding like a views issue, but it is VBO issue.

This issue occurs when sorting a views table by a column in which multiple rows may share one or more identical field values. In this instance, each page load of the view results in a random sort order for said values. For example the following data may appear as such when sorted by the first column:

A | 1
B | 2
B | 3
C | 4

But if you reload the page, you may see this order, still sorted by the first column.

A | 1
B | 3
B | 2
C | 4

Since we are using the views table sort and not the field sort, this means that the there is no secondary sort, nor would that makes sense since we can arbitrarily sort by any column anyway.

The problem here is that VBO does not seem to truly remember which values were selected upon performing an operation. It remembers the POSITION, but since VBO seems to be actually reloading the entire view when performing this operation, the order of the rows gets changed between viewing the view and performing the operation.

The end result is that operations may be performed on the wrong rows.

This can be reproduced by creating a views table similar to the one above, where multiple rows match on once column but not another. IMPORTANT: You must be able to reproduce the view sorting randomness in order to see this happen. If your view is not randomly ordering the rows with matching values when sorting by that column, this behavior will not occur. I've been told that this is standard views behavior but I cannot always reproduce it.

The implications of this are serious because when it can result in operations being performed on the wrong data.

Comments

chrisgross’s picture

A dpm on views_bulk_operations_form_validate shows that $form_state['input']['views_bulk_operations'] does not match $form_state['values']['views_bulk_operations'], indicating that the 'input' values (which are correct) are not being translated to the 'values' values (which are not).

bojanz’s picture

What action are you using to test this? Just "Execute PHP script"?

chrisgross’s picture

No, I'm using operations like delete. I can easily verify the incorrect selection without performing any operations by disabling "skip confirmation."

davidwhthomas’s picture

I've had the same issue here:

The selected nodes on the confirm form don't match those selected in the original view.

It appears to occur because the view content has changed between selecting and applying a batch update, e.g new items entered while on the configure step.

This happens for example when new content is published it appears in this "Published articles" view during the update.

It does indeed appear to be related to VBO using the row position somewhere, rather than the actual entity id?

It's quite major as an editor can inadvertently batch update/delete the wrong nodes.

Subscribing.

P.S VBO rocks :-)

bojanz’s picture

Status: Active » Fixed

Thanks guys, you helped me finally understand what the issue is. And ouch, what a nasty one :/

This is a general Views Form issue. Opened a Views issue and posted a patch to #1473276: Views Form is not cached, can lead to data loss and corruption.
Also committed the same fix to VBO (to be removed when most people upgrade to a Views version that includes the patch):
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/0ba28be

davidwhthomas’s picture

Awesome sleuthing bojanz, thanks for your insight on this issue!

Great to see it fixed.

best regards,

David

P.S Thanks again for your hard work on this excellent module. Great stuff.

Status: Fixed » Closed (fixed)

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

macman’s picture

Hi

I think I am having the same problem on my site. However, I am running vbo 6.x-1.10 so the above fix does not apply. Can you please give me instructions about what to change? Thanks.

bojanz’s picture

Which part of "upgrade to 6.x-1.x-dev, retest, open a new issue if the problem persists" didn't you understand?