VBO doesn't preserve duplicate results

This issue has come back, I assume as a result of the rewrite from 6.x to 7.x.
The culprit is here: (views_bulk_operations.module ~line 470)

/**
 * Goes through the submitted values, and returns
 * an array of selected rows, in the form of
 * $entity_id => $row_index.
 */
function _views_bulk_operations_get_selection($vbo, $form_state) {
  $selection = array();
  $field_name = $vbo->options['id'];

  if (!empty($form_state['values'][$field_name])) {
    // If using "force single", the selection needs to be converted to an array.
    if (is_array($form_state['values'][$field_name])) {
      $selected_rows = array_filter($form_state['values'][$field_name]);
    }
    else {
      $selected_rows = array($form_state['values'][$field_name]);
    }
    // At this point, $selected_rows is an array of $row_number => $entity_id.
    // We need the $entity_id to be the key, so the array gets flipped.
    $selection = array_flip($selected_rows);
  }

  return $selection;
}

Selected rows are keyed by entity id.
I am pretty fresh to VBO and so unsure about the implications of changing this functionality. I am looking into this further, but would greatly appreciate any opinions from those more familiar with the module as to whether this is actually feasible.

This is by design. VBO takes the entity_id from the row, loads the entity and passes it to the operation (action, rule).
5 duplicate rows = 5 same entity ids = 5 same entity objects.

What is your use case for this?

I thought that might be the case.

I have two multi-value taxonomy fields that take terms from the same vocabulary. One is exposed to the user used to contain values waiting for approval, the other holds approved terms. I was hoping to handle the approval workflow with a simple custom action & VBO.
Unfortunately because the taxo fields are multi value, I need to display a row for each value in the pending field i.e. duplicate entity rows.

Thanks for your quick response btw :)

You'll notice that what you're actually bulk modifying are terms, not nodes.

1) Create a node view, add a title, nid, taxonomy field (setup so that it creates a row for each term). I'm guessing you already have this part done.
2) Add a taxonomy relationship (when you click the "Add relationship" link, you'll see a relationship named the same as your taxonomy field).
3) Now add a "Taxonomy term: Bulk operations" field and have it use the relationship defined in #2.
So, when you execute a bulk operation now, it will get a taxonomy term entity.
Of course, you still need to know which node the term belongs to. If you specify "pass rows" => TRUE for your custom action in your hook_action_info(), it will pass the views row that was selected, and you can have your nid or whatever else you need there.

Of course, this falls apart if the view has more than one same term, so you'd pretty much have to limit the view to one node only (which if I understand correctly is already the case).

Might be willing to consider allowing duplicates, with a patch such as the attached one. Too tired to decide if it's a mistake.

Thank you very much, your suggestion works! Heh, I was thinking about the problem entirely the wrong way.
I haven't tested the patch as your suggestion solves my problem but I will leave the issue as "needs review" in case you want to pursue it.
I really appreciate your help bojanz, thanks again!

- Tom

Whoops got a little excited there and spoke too soon :)

Of course, this falls apart if the view has more than one same term, so you'd pretty much have to limit the view to one node only (which if I understand correctly is already the case).

In our case the taxo terms are on users and we ideally don't want to limit to one user.

Looking at the patch, you have made adjustments to the Rules component class. I was planning on just writing an action, I assume I can do something similar with the actions class.

Ok sorry for all the noise, that last comment should probably be best ignored entirely.

Here is a working version of the patch above, it appears to solve my specific problem quite effectively.
I have no idea however, how this will effect existing actions or whether it is a smart architectural decision. I will continue to test :-)

Committed a real fix:
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/f2917...

Please test and let me know if you encounter any issues.

Seems to be working well, thanks!