'Please select at least one item' - after upgrading to 7.x-3.4

Hi,

I can confirmed : v3.4 breaks one line or multiple lines selection when an execute button is clicked.

Revert to v3.3 works fine.

In ubercart order views with vbo v3.4 :

the value of the checkbox is empty.
value=""

in 3.3 the value is the order_id

I'm seeing the same symptoms in my application, which does not use Ubercart. The Execute button properly enables/disables with the checked rows being selected/deselected. Multiple are allowed. But when Execute is clicked, the message "Please select at least one item" is displayed. Downgrading to 7.x-3.3 restores the proper operation, but the view cannot properly be edited to adjust the bulk operations field. Downgrading to 7.x-3.2 restores the ability to edit the view.

In my case, the problem was that the view is of a custom table, and in module_views_data(), the table lacked the ['table']['entity type'] = 'xxx' entry. See http://drupal.stackexchange.com/questions/114364/adding-vbo-to-an-entity

I can't say if this is the problem with the ubercart, but perhaps it will help someone.

Same problem here. I downgrade to 7.x-3.3 and everything is working.

#2855939: Bulk operation buttons don't work after upgrade to 3.4 when Force Single selected. This a duplicate, I am looking into it, would like you to test the patch.

@bruceshort can you please update your issue summary with clear steps to reproduce your issue and please define what you mean by "not working".

@bruceshort I can't reproduce with the steps you've provided. Could you post in a file the exported view code maybe to help? Or reproduce the steps with simplytest.me?

Same problem after upgrading to 3.4 "Please select at least one item."
The message is displayed after one line is selected and the submit button is clicked.

@sandrymend same question for you, read comment #12

Hi Joel,

sorry I went quiet on you after the first couple of posts. I got back to the issue and rolled the test site back to 3.3 and tested all permutations. We use VBO to select orders in Ubercart for printing, bulk status changes or bulk delete of abandoned orders for example. And all permutations work perfectly in 3.3 including dates, operations, etc. When we upgrade to 3.4, selection of orders by date also works perfectly. We can select orders by order type and specific date or date range.

The issue arises when we move to the next form which is the operation form for printing or deleting orders. When we select the orders to delete for example on the check-box beside the order, the error message:

Please select at least one item.

is shown in the message box. We tried the two cases where the date selection was not used and then with a date selection entered.

Does this help? Is there anything more we can provide? Is this the right thread?

Al

@alh Totally the right thread. Ideally I'd love the minimum steps to reproduce this issue. aka Generate data for X node type and create a view with these fields and a VBO field and click here to see the error...

If you can't do that, an export of the view uploaded in a .txt file (not dumped into a comment please) would potentially help but the less dependencies to reproduce this the better (like not needing ubercart to reproduce would be ideal).

Hi Joel. Took another step towards understanding the uc_orders view and it behaviour. The ability to print and delete multiple orders is offered as an ubercart feature as of Ubercart 7.4 (before it existed as a separate module - Delete orders using VBO). The difficulty might actually lie here. As I mentioned in the previous postings, I thought that the error message might be due to the existence of two VBO forms in the same view. So I removed the date filter from the uc_orders view. I thought that the delete/print VBO operation would work again but no. The same error condition appears. Therefore I now believe that the problem is to be found in the interaction between the 'Delete orders using VBO' feature in Ubercart and VBO. I will therefore raise the issue on Ubercart and see if we can get some discussion going there. Perhaps there already is a thread. I'll check it out.
Al

Sorry - perhaps a bit misleading on my last posting. After enabling VBO with Ubercart, you have the ability to print multiple orders. If you enable the module 'Delete orders using VBO', you then have the ability to print or delete multiple orders in Ubercart. Neither one works properly however in Ubercart 7.3.10. Posting issue now on ubercart. So all live sites are still on VBO 3.3 pending resolution of the issue.

Can you add the list of modules needed to reproduce this into the issue summary and their versions?

I tried to start reproducing this with simplytest.me but ubercart doesn't have a 7.4 only 7.3, can you confirm?

Hi Joel,

the stable version of Ubercart is 7.x-3.10 and the problem exist in this version.

Those module are needed and should be included:

uc_cart
uc_order
uc_product
uc_store

Once enabled, there is a " Store / Orders" view in the menu

Plus those other required:

Image (enabled), File (enabled), Field (enabled), Field SQL storage (enabled), Rules (enabled), Entity tokens (enabled), Entity API (enabled), Views (enabled), Chaos tools (enabled)

I think this issue may be the culprit:
#1334374: Re-use generic entity views table But I'm not sure, please reverse that patch and see if it helps you. (remember to clear the caches after).

Not quite sure if I want to revert that patch until I understand the implications but you can help test this please.

You'd like us to revert the patch in #36 issue #1334374 and see if it presents a fix. Just want to be sure before doing so. Will do so once confirmed then let you know.

Yes, essentially this command inside of vbo 3.4 project folder.

curl https://www.drupal.org/files/issues/1334374-36-use_generic_entity_tables.patch | patch -p1 -R
drush cc all

Reverted and now print/delete operations work fine on multiple orders in 3.4. Going to add back in the date filter and re-test but believe you have successfully isolated the issue.

I will see if I can take a look and figure out what's going on here when I get a chance (I was involved in writing the patch that seems to conflict). My guess without looking would be that either there is something ubercart doesn't do properly with its entity definition or the patch makes an assumption about entity definitions that is not reliable.

One comment mentions that the value attribute for the checkbox is empty and is that the case with the reproducible issue (and I assume that is resolved when the patch is applied)? If so it may be related to the way we get the ID...

Hello

I don't think it is Ubercast, because I had the same problem and I have not it installed. I solved by downgrading VBO. I use it with https://www.drupal.org/project/better_watchdog_ui Thanks @andrewbelcher for your interest.

So the problem here is that neither Better Watchdog UI or Ubercart specifiy the entity type in their views data definition for the base table. If you look at how views defines the table for an entity (in this case user):

  $data['users']['table']['group']  = t('User');

  $data['users']['table']['base'] = array(
    'field' => 'uid',
    'title' => t('User'),
    'help' => t('Users who have created accounts on your site.'),
    'access query tag' => 'user_access',
  );
  $data['users']['table']['entity type'] = 'user';

You see it specified $data[BASE_TABLE]['table']['entity type'] = ENTITY TYPE;, which is the key piece of information missing. Without that views_plugin_query_default::get_result_entities is unable to load the required information. In the case of Better Watchdog UI, adding the entity type as follows resolves the issue:

function better_watchdog_ui_views_data_alter(&$data) {

  // Base table.
  $data['watchdog']['table'] = array(
    'base' => array(
      'field' => 'wid',
      'title' => t('Watchdog'),
      'help' => t('Table that contains logs of all system events.'),
      'weight' => 25,
    ),
    'group' => t('Watchdog'),
    'join' => array(
      'users' => array(
        'field' => 'uid',
        'left_field' => 'uid',
      ),
    ),
    'entity type' => 'better_watchdog_ui_watchdog',
  );

  ...
}

Ubercart will be the same resolution.

@joelpittet I'll leave you to decide whether you want to close this issue and have separate ones opened on the respective modules or change this to be one of them...

Excellent - making progress. I raised the issue on Ubercart a couple of days ago - issue 2861925. I will add to the thread with @andrewbelcher observations to 2861925.

Thank you @andrewbelcher that solves my issue too!
See my fix at: https://www.drupal.org/node/2863373

Glad to see this on the list. Do not use Ubercart and having the same issue. Tried #23 but did not resolve, so rolling back to previous. Can try looking into this further later when I get more time, otherwise likely may wait for 3.5.

@andrewbelcher I think the safest bet is to revert that patch unfortunately because it looks like there are a few related issues that popped up from this. I very much appreciate your response on this issue and for making clear the solution and problem.

That will break anything that now depends on the new behaviour. Based on the problem, I think it should be easy enough ensure the entity type is set as part of the hook alter which should resolve the issue.

@andrewbelcher What depends on the new behaviour? I think not enough time has passed to create strong dependencies, though maybe there can be both for BC?

Well, there was quite a lot of interest in the search api issue that depended on this. Reverting it would stop search api working with VBO, which for me is the main use case.

BC layer should be quite straight forward as we just need to check that the entity type is set on the base table as part of VBOs views data alter. I'll write a patch on Monday.

Here is a patch that should resolve the issue by doing the work our end. As I think that is a bad design principle to have, I am also using watchdog to log a warning about the fact we're having to do it.

Thanks for the patch, I'll let the others review it though I'm going to see if I can't grep all the D7 projects that implement the HOOK_views_data(_alter) to see where the entity type is not set. May take a while I'm re-downloading all d7 modules;) ...

@andrewbelcher noticed that the other patch also caused a bunch of issues with incorrect results because the field handler changed base class:

-class views_bulk_operations_handler_field_operations extends views_handler_field {
+class views_bulk_operations_handler_field_operations extends views_handler_field_entity {

And in doing so, the get_value() checks the entity object instead of the entity id and can't find it so returns FALSE.
if (isset($this->entities[$this->view->row_index])) {

That caused these two issues to be filed:
#2853029: views_bulk_operations_action_load_list not working
#2862858: Rule action "Load a list of entity IDs from a VBO view" returns list with empty values

I think it's probably safer to revert that change until we can put in some tests to cover off the bugs that surfaced.

@joelpittet
Same problem after upgrading to 3.4 "Please select at least one item."
The message is displayed after one line is selected and the submit button is clicked.

Reversed the update and applied the changes by file and noticed that this file's change
-class views_bulk_operations_handler_field_operations extends views_handler_field {
+class views_bulk_operations_handler_field_operations extends views_handler_field_entity {
caused the issue.

@sandrymend thanks for confirming what I was mention in #38

Are you sure the patch above doesn't resolve all those problems?

@andrewbelcher
the patch in #36 doesn't help (the value for checkbox ids are still empty : see my post #4)

@joelpittet
revert in #23 fixes the problem with bulk printing ubercart orders
the input ids of checkboxes are set (value="the_order_id_number"), same as in vbo v3.3

Are there detailed instructions on how to fix old modules (like Ubercart) that are now broken?

If so, please point to them. If not, can someone please write them?

Please assume I know very little about Views.

@joelpittet
revert in #23 fixes the problem with bulk deleting ubercart orders
the input ids of checkboxes are set (value="the_order_id_number"), same as in vbo v3.3

The patch in #36 looks great to me and it is working fine.

Thank you!

If the patch in #36 works, then I think that is far more preferable to the revert. Are there any details of what context the #36 didn't work?

Looking at the logic, patch 36 surely fixes the problem. But I'm not sure this should be fixed by VBO...

As others already told, this problem happens if an entity table definition in hook_views_data() doesn't have 'entity type'. In general, it's defined by Entity API module automatically unless the module changes the table definition. So isn't it better to fix this problem in each module which defines the entity type? I'm not sure but I believe, this case is quite rare because only ubercart and better_watchdog_ui are reported to have this problem so far.

Re #46:

Are there any details of what context the #36 didn't work?

I think the patch 36 may not fix the problem in a very rare case where hook_views_data_alter() of a module which defines an entity type is invoked after views_bulk_operations_views_data_alter().

For example, better_watchdog_ui implements hook_views_data_alter() in the following way.

/**
 * Implements hook_views_data_alter().
 */
function better_watchdog_ui_views_data_alter(&$data) {

  // Base table.
  $data['watchdog']['table'] = array(
    'base' => array(
      'field' => 'wid',
      'title' => t('Watchdog'),
      'help' => t('Table that contains logs of all system events.'),
      'weight' => 25,
    ),
    'group' => t('Watchdog'),
    'join' => array(
      'users' => array(
        'field' => 'uid',
        'left_field' => 'uid',
      ),
    ),
  );

If this is invoked after views_bulk_operations_views_data_alter(), the problem is not fixed. Is my understanding correct?

I agree that it should really be fixed elsewhere, but the discussion here is about reverting use of the generic entity tables as other modules do not correctly implement things.

Good point in #47 about implementation order, I suggest we also implementhook_module_implements_alter() to ensure we run last.

The issue arises when entities are not created by the entity api, but are simulated to allow access to a custom table. This was the case in my custom module. Since this is a new requirement by VBO, it might be best to define the entity_type if it is missing.

I also have a client using VBO to select Ubercart orders and update order status in bulk. I am having the same original issue, and after applying patch #36, the issue persists.
Again, patch #36 did not resolve the issue for me. I am still getting the "Please select at least one item" error.
Will revert their production site, but I do have a development site for testing.

Here is an updated patch with a hook_module_implements_alter() to make ours run last so the entity type we add doesn't get overridden.

#51 #47 etc - could you test to see if this resolves your specific scenario.

Just to reiterate - I think adding this change is a bad idea. It is not VBO's responsibility to fix bad implementation by other modules. We depend on Entity, which provides this automatically for any defined entity (see profiles/opencrm_kickstart/modules/contrib/entity/views/entity.views.inc:376). The only ways for this scenario to occur are:

• A module overriding the views controller class key of the entity definition with a controller that does not do what is done in the default views controller.
• A module using hook_views_data_alter() to blindly override the existing definition without providing the entity type to the base table (or whoever else knows what they are wiping out).

Both of these are incompatibilities between the module that does it and Entity, which then causes an incompatibility with VBO. I do not think that this is in any way VBO's responsibility and I do not think it sensible for VBO to be attempting to fix this for those modules, as it makes other modules who want to adjust VBO's views definitions (e.g. changing a label) jump through more hoops to be able to alter the definitions.

Still getting the error after apply patch from #51.

Same error after patch #51 and checkbox ids are still ""

#52/53, what modules do you have and which versions? Which view, or if us custom can you provide the export?

Drupal v7.54
Views v3.16 (was the same with 3.15)
VBO v3.4
Ubercart v3.10

The view is not custom.
It is named "uc_orders" and its path is /admin/store/orders/view

Drupal and all modules using current versions.
Drupal 7.54
Ubercart 7.x-3.10
Views 7.x-3.16
VBO 7.x-3.4

I am using a view (uc_order) from Ubercart, but have modified it to suit the client's needs.

Apologies, I had a mistake in the patch, could you try this one instead?

#57 applied on 7.x-3.x-dev (2017-Apr-06) fixes the error on ubercart 3.10
Thank you

I wonder if the watchdog line is really needed. Creates lots of log pollution.

Admins won't necessarily understand that some entity types are not defined and views_bulk_operations warnings will pop up very often (they might wonder what is going on).
On my website with ubercart, these warning pops up 12 times every time the cache is cleared (field_collection, entity rules, entityform, taxonomy, etc.)

The comment line should be more than enough (// Check that the base table has the entity type key set.)

Re #58:

I wonder if the watchdog line is really needed. Creates lots of log pollution.

I think it's better to put the watchdog line because without it developers don't notice that the problem lies in other modules and that VBO is just working around it.

@andrewbelcher thank you for patches. I think the patch #57 is fine though I haven't tested it.

Just my 2 cents about the watchdog logs :

popping up warnings everyday about modules like field_collection, ubercart, entityform etc. might annoy quite a few devs and admins.

The patch is great and both fix works really well now but I also think the watchdog messages should not be included.

The watchdog messages are only generated on building the views data, which is cached. So although you may get a fair amount of it during development, a production site is unlikely to see it often.

Maybe but these watchdog messages are reporting a problem already fixed and they do not give much clue as to what to fix. For example, on one of my website, I get these in batch all the time :

WD views_bulk_operations: Base table for Nœud does not have the entity type explicitly set.                                                                                                              [warning]
WD views_bulk_operations: Base table for Terme de taxonomie does not have the entity type explicitly set.                                                                                                 [warning]
WD views_bulk_operations: Base table for Flagging does not have the entity type explicitly set.                                                                                                           [warning]
WD views_bulk_operations: Base table for Rediriger does not have the entity type explicitly set.                                                                                                          [warning]
WD views_bulk_operations: Base table for Fichier does not have the entity type explicitly set.                                                                                                            [warning]
WD views_bulk_operations: Base table for Vocabulaire de taxonomie does not have the entity type explicitly set.                                                                                           [warning]
WD views_bulk_operations: Base table for Utilisateur does not have the entity type explicitly set.                                                                                                        [warning]
WD views_bulk_operations: Base table for Configuration de Rules does not have the entity type explicitly set.                                                                                             [warning]

Where do I begin to look or who do I contact to fix all of these?

Since these watchdog messages come from a new requirement of the VBO module already fixed in the VBO module with the patch, I would suggest to simply drop the watchdog messages and commit the rest of the patch!

Thanks for your time.

Patch #57 works fine for me. Better Watchdog UI module is now working properly again. For a dev's point of view, I also do think the watchdog messages generated by the patch are more than enough!

Many Thanks for all your kind help! :)

The patch in #57 should not be hidden.

Patch from #55 works but unnecessarily fixes up 'entity type' and logs watchdog for ALL records due to missing ['table'] from the if(). Re-rolled it and attached.

@LeDucDuBleue Sorry for my inconvenience... :(

Patch #66 works for me.
Thank you!

Unfortunately this patch is not providing a work-around for us. We're still seeing "Please select at least one item." on our bulk operations views when trying to select and publish content.

This appears to be related to the implementation of taxonomy by the views module:

"Base table for Taxonomy vocabulary does not have the entity type explicitly set."

and also the redirect module:

"Base table for Redirect does not have the entity type explicitly set."

My understanding is that there needs to be a line like

$data['taxonomy_vocabulary']['table']['entity type'] = 'taxonomy_vocabulary';

in taxonomy_views_data() however this also did not fix the issue in our case.

And I'm not sure what the equivalent would be for the redirect module. Any help here?

Applied the patch from #66 and everything is working fine including bulk print and delete of orders in Ubercart as well as bulk publish and un-publish of content in general. Watchdog logging also reasonable. After patching, and upon cache clear the log messages were:

views_bulk_operations 04/23/2017 - 11:12 Base table for Order does not have the entity type...
views_bulk_operations 04/23/2017 - 11:12 Base table for Cart item does not have the entity...
views_bulk_operations 04/23/2017 - 11:12 Base table for Taxonomy vocabulary does not have the...
views_bulk_operations 04/23/2017 - 11:12 Base table for Redirect does not have the entity type...

Which I gather it not unexpected. I plan to do some more testing before going live but looking good.

Thanks guys.

#66 works here too (ubercart orders)

Thanks

#23 actually worked for our site where we aren't running Ubercart or Better Watchdog UI... is it recommended to still use this patch? Or switch to one of the later patches? Upon updating to 3.4 we had the same issues where if a row was selected, we'd receive the "Please select at least one item." error once the Execute button was pressed. In our case the View looks to be working heavily with Organic Groups. We're using VBO for several tables on the site, one was not affected by the change, but another one was which is used to modify user roles.

Edit: Upon further inspection, the checkboxes in one of the not-affected tables appear to be missing after adding this patch so I assume will need to use a different patch.

@katej_ri #23 is a revert, it seems like there is some effort to keep moving forward, could you try working with #66

@joelpittet Thanks. Gave #66 a try this morning and it actually made all of the views that use this module disappear completely. All of the views also use Organic Groups (7.x-2.9). The first noticeable view where this occurred uses "OG membership: Entity_type (=user)" as one of the filter criteria. The other views do not have that specifically set as a filter criterion, but have various OG membership roles inherited for the contextual filters and relationships.

In sites/all/modules/og/includes/views/og.views.inc lines 112-122 I did find a reference to hook_views_data_alter that addresses entities, but looks like it skips them if they're empty. I wonder if this is the issue? I'm fairly new to this so please excuse any errors on my part.

/**
 * Implements hook_views_data_alter().
 */
function og_views_data_alter(&$data) {
  $group_content_entities = og_get_all_group_content_entity();
  $group_entity_types = og_get_all_group_entity();

  foreach (entity_get_info() as $entity_type => $info) {
    if (empty($group_content_entities[$entity_type]) && empty($group_entity_types[$entity_type])) {
      continue;
    }

Applied patch #66 but we still get the same issue "Please select at least one item."
After patching and cache cleared the log messages were a list of bunch of modules: the entity type explicitly set.

Interesting - VBO 3.4 and Date do not get along too well. We are using both the Date and Delete orders using VBO modules. In order for the Delete orders using VBO to work, the Date module has to be disabled. I should add that this is with VBO 3.4 and patch #66. If Date is enabled the Delete orders using VBO form disappears. Warnings, error are as below:

php 04/27/2017 - 12:56 Notice: Undefined index: date_filter in views_handler...
php 04/27/2017 - 12:56 Notice: Undefined index: operator in views_handler...

More specifically:

Notice: Undefined index: date_filter in views_handler_filter->accept_exposed_input() (line 1279 of /home/basicsby/public_html/sites/all/modules/views/handlers/views_handler_filter.inc).

I will do some more digging and report further.

Al

OK - sorry. I see that when Date is disabled it leaves the orders view corrupted. Once I removed the corrupted filter, we are back to normal. So VBO with Delete orders with VBO is working fine now. We will turn off Date on the production sites for now. And investigate the challenge more on the test site.

Al

Tried again and tables are showing this time (not sure what happened last time), but still getting "Please select at least one item" error. This doesn't happen on all of the table views on our site though, only the one used to specifically modify and change user roles (using Organic Groups 7.x-2.9).

I may have found the issue. I am using VBO 7.x-3.4 and the patch provided in #66. Even after applying the patch, I still got the "Please select at least one item" error. Looking at the function _views_bulk_operations_get_selection on lines 678-698 in views_bulk_operations/views_bulk_operations.module I found that the issue might be with the array_filter function on line 691. See documentation for that function: http://php.net/manual/en/function.array-filter.php

Code block in question:

/**
 * Goes through the submitted values, and returns
 * an array of selected rows, in the form of
 * $row_index => $entity_id.
 */
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])) {
        dpm($form_state['values']);
      $selection = array_filter($form_state['values'][$field_name]);
    }
    else {
      $selection = array($form_state['values'][$field_name]);
    }
  }
  return $selection;
}

I believe the problem is this:
When a user checks a checkbox on the table (created by the Bulk Operations field in the View), that checked box changes from an Integer value of 0 to a Boolean value of FALSE (see attached screenshot - the second item in the 3-item listed is checked). If you use the array_filter function to handle your array, the second argument is a callback. If that is not provided (which it is not in this code), it defaults to removing all of the values in your array that have a boolean value of FALSE. As a result, it removes all of the things that the user checked, thus returning an empty $selection variable at the end of the function which is then checked by the views_bulk_operations_form_validate function starting on line 541, where the error message is returned.

If you set the $selection variable equal to the array without using the array_filter function, the selection and execution moves forward with no error and works successfully. Edit: Actually looks like it does not work successfully. It does move to the next page, where I choose the OG role I want to remove from the user. I click OK and it then tells me I have selected 0 items. When I click Save, it tells me it successfully performed an operation on 3 items, which it clearly did not do.

I'm not sure if array_filter is a necessary function for this module, so I don't want to write a patch to remove it with my limited knowledge of the module code. I'm also not sure why checking the checkbox would return a Boolean value of FALSE rather than an Integer value of 1 or Boolean value of TRUE. Would be great to hear other ideas or feedback about this!

@katej_ri, I wish I'd read your explanation earlier. I finally tracked down exactly what you (very nicely) explained. Thanks for taking the time to lay that out. As a newbie, I'm realizing I need to read this forum sooner rather than spend an hour tracking down something someone else already figured out. :-)

That said, I think it's a little deeper than being an array_filter issue because _views_bulk_operations_get_selection() is the same in 7.x-3.3 and 7.x-3.4 (and people are only just now seeing this issue in 3.4).

I'm not sure what the root cause is, but the fact that $form_state['input'][$field_name] values are set to "" for selected checkboxes and unselected checkboxes are NULL, that seems the deeper issue. (And, to your point, $form_state['values'][$field_name] checked values are FALSE and unselected are zero -- the issue is further upstream). (where $field_name == "views_bulk_operations")

I've reverted to 7.x-3.3 and it fixed the issue for us. I'm seeing a lot of discussion, but I've not seen (missed?) the final / definitive patch that corrects this.

@tomarnold2 I am new myself so hoping for some more discussion about this, there definitely seem to be more people still having the issue! I'm glad that my post was even retroactively helpful.

I agree that it's probably deeper than array_filter but I haven't gotten there yet. Planning to keep digging as time allows. I've also reverted to 3.3 and am using a patch that was integrated with 3.4 that fixed one of our bugs (the reason we upgraded to 3.4).

The latest patch in this thread did not fix the problem for me (and it appears others) so I don't think there is a definitive patch yet that is a universal fix.

In digging further, I wonder if the issue is related to views_bulk_operations_handler_field_operations.inc lines 280 - 303.

    // At this point, the query has already been run, so we can access the results
    // in order to get the base key value (for example, nid for nodes).
    foreach ($this->view->result as $row_index => $row) {
      $this->view->row_index = $row_index;
      $id = $this->get_value($row, $this->real_field);

      if ($this->options['vbo_settings']['force_single']) {
        $form[$this->options['id']][$row_index] = array(
          '#type' => 'radio',
          '#parents' => array($this->options['id']),
          '#return_value' => $id,
        );
      }
      else {
        $form[$this->options['id']][$row_index] = array(
          '#type' => 'checkbox',
          '#return_value' => $id,
          '#default_value' => FALSE,
          '#attributes' => array('class' => array('vbo-select')),
        );
      }
    }
  }

Update to 3.4 with patch #66 on line 282 replaced $entity_id = $this->get_value($row) with two lines:

$this->view->row_index = $row_index;
$id = $this->get_value($row, $this->real_field);

When I dpm($id) it is empty. I'm not sure if this then influences the #return_value of the checkbox which is then set to $id. I wonder if it has to do with the fact that for get_value it is getting the field from $row, and if you dpm($row), that particular field (real_field) doesn't exist in that array. It does exist in $this. Tried replacing $row with $this, but still empty. It should be printing 'id' I think? I'm not familiar with the get_value function so I wonder if there is some issue with the value it returns. By changing the line to $id = $this->real_field; I can select a checkbox and move forward to the next screen, but it then tells me that I've "Successfully selected the following 0 items" and then it won't let me finish the operation.

This all looks like the same issue with base tables being incorrectly configured. Can you do the following (in the same place after the $id = $this->get_value($row, $this->real_field);):

dvm(array('options' => $this->options, 'definition' => $this->definition, 'table' => $this->table, 'data' => views_fetch_data($this->table)));

If you can paste up the results, we can hopefully see what's going wrong.

@andrewbelcher I did that and for each entry in the table there is quite a bit of information. Not sure how best to paste the full results but here is a result from one row with definition and data expanded.

@andrewbelcher Sorry about that, did dpm not dvm. Here are results of dvm:

array(
  'options' => array(
    'id' => 'views_bulk_operations',
    'table' => 'views_entity_og_membership',
    'field' => 'views_bulk_operations',
    'relationship' => 'og_membership_rel',
    'group_type' => 'group',
    'ui_name' => '',
    'label' => 'OG membership',
    'exclude' => 0,
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'absolute' => 0,
      'external' => 0,
      'replace_spaces' => 0,
      'path_case' => 'none',
      'trim_whitespace' => 0,
      'alt' => '',
      'rel' => '',
      'link_class' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'nl2br' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'more_link' => 0,
      'more_link_text' => '',
      'more_link_path' => '',
      'strip_tags' => 0,
      'trim' => 0,
      'preserve_tags' => '',
      'html' => 0,
    ),
    'element_type' => '',
    'element_class' => '',
    'element_label_type' => '',
    'element_label_class' => '',
    'element_label_colon' => 1,
    'element_wrapper_type' => '',
    'element_wrapper_class' => '',
    'element_default_classes' => 1,
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'hide_alter_empty' => 1,
    'vbo_settings' => array(
      'display_type' => '1',
      'enable_select_all_pages' => 1,
      'row_clickable' => 1,
      'force_single' => 0,
      'entity_load_capacity' => '10',
      'skip_batching' => 0,
    ),
    'vbo_operations' => array(
      'action::views_bulk_operations_delete_item' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_delete_revision' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_script_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_modify_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
        'settings' => array(
          'show_all_tokens' => 1,
          'display_values' => array(
            '_all_' => '_all_',
          ),
        ),
      ),
      'action::og_set_state_action' => array(
        'selected' => 1,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::og_user_roles_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_argument_selector_action' => array(
        'selected' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
        'settings' => array(
          'url' => '',
        ),
      ),
      'action::og_membership_delete_action' => array(
        'selected' => 1,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::system_send_email_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
    ),
  ),
  'definition' => array(
    'handler' => 'views_bulk_operations_handler_field_operations',
    'click sortable' => FALSE,
    'group' => 'Bulk operations',
    'title' => 'OG membership',
    'help' => 'Provide a checkbox to select the row for bulk operations.',
    'real field' => 'id',
  ),
  'table' => 'views_entity_og_membership',
  'data' => array(
    'rendered_entity' => array(
      'title' => 'Rendered OG membership',
      'help' => 'The OG membership of the current relationship rendered using a view mode.',
      'field' => array(
        'handler' => 'entity_views_handler_field_entity',
        'type' => 'og_membership',
        'real field' => 'entity object',
      ),
    ),
    'views_bulk_operations' => array(
      'title' => 'OG membership',
      'group' => 'Bulk operations',
      'help' => 'Provide a checkbox to select the row for bulk operations.',
      'real field' => 'id',
      'field' => array(
        'handler' => 'views_bulk_operations_handler_field_operations',
        'click sortable' => FALSE,
      ),
    ),
    'table' => array(
      'join' => array(
        'og_membership' => array(
          'left_table' => 'og_membership',
        ),
        'entity_og_membership' => array(
          'left_table' => 'entity_og_membership',
        ),
        'views_entity_og_membership' => array(
          'left_table' => 'views_entity_og_membership',
        ),
      ),
      'entity type' => 'og_membership',
      'group' => 'OG membership',
    ),
  ),
)

Could you also get the debug of $row and $this->aliases please?

I've taken some values out of the variables in the $row array to protect user privacy. Each one has a value though, there are no empty variables for $row. Looks like $this->aliases is an empty array.

$row:

(object) array(
  'og_membership_users_etid' => '',
  'uid' => '',
  'users_name' => '',
  'og_membership_users_state' => '1',
  'og_membership_users_group_type' => 'node',
  'og_membership_users_gid' => '',
  'og_membership_users_created' => '',
  'field_data_field_first_name_user_entity_type' => 'user',
  'field_data_field_last_name_user_entity_type' => 'user',
  'field_data_field_affliation_user_entity_type' => 'user',
  'field_data_field_affiliation_type_user_entity_type' => 'user',
  '_field_data' => array(
    'uid' => array(
      'entity_type' => 'user',
      'entity' => (object) array(
          'uid' => '',
          'name' => '',
          'pass' => '',
          'mail' => '',
          'theme' => '',
          'signature' => '',
          'signature_format' => 'filtered_html',
          'created' => '',
          'access' => '',
          'login' => '',
          'status' => '1',
          'timezone' => 'America/New_York',
          'language' => '',
          'picture' => '0',
          'init' => '',
          'data' => FALSE,
          'roles' => array(
            2 => 'authenticated user',
          ),
          'og_user_group_ref' => array(
            'und' => array(
              array(
                'target_id' => '',
              ),
              array(
                'target_id' => '',
              ),
              array(
                'target_id' => '',
              ),
              array(
                'target_id' => '',
              ),
              array(
                'target_id' => '',
              ),
              array(
                'target_id' => '',
              ),
            ),
          ),
          'field_first_name' => array(
            'und' => array(
              array(
                'value' => '',
                'format' => NULL,
                'safe_value' => '',
              ),
            ),
          ),
          'field_last_name' => array(
            'und' => array(
              array(
                'value' => '',
                'format' => NULL,
                'safe_value' => '',
              ),
            ),
          ),
          'field_affliation' => array(
            'und' => array(
              array(
                'value' => '',
                'format' => NULL,
                'safe_value' => '',
              ),
            ),
          ),
          'field_affiliation_type' => array(
            'und' => array(
              array(
                'tid' => '28',
              ),
            ),
          ),
          'rdf_mapping' => array(
            'rdftype' => array(
              'sioc:UserAccount',
            ),
            'name' => array(
              'predicates' => array(
                'foaf:name',
              ),
            ),
            'homepage' => array(
              'predicates' => array(
                'foaf:page',
              ),
              'type' => 'rel',
            ),
          ),
          'force_password_change' => '0',
        ),
    ),
  ),
  'field_field_first_name' => array(
    array(
      'rendered' => array(
        '#markup' => '',
        '#access' => TRUE,
      ),
      'raw' => array(
        'value' => '',
        'format' => NULL,
        'safe_value' => '',
      ),
    ),
  ),
  'field_field_last_name' => array(
    array(
      'rendered' => array(
        '#markup' => '',
        '#access' => TRUE,
      ),
      'raw' => array(
        'value' => '',
        'format' => NULL,
        'safe_value' => '',
      ),
    ),
  ),
  'field_field_affliation' => array(
    array(
      'rendered' => array(
        '#markup' => '',
        '#access' => TRUE,
      ),
      'raw' => array(
        'value' => '',
        'format' => NULL,
        'safe_value' => '',
      ),
    ),
  ),
  'field_field_affiliation_type' => array(
    array(
      'rendered' => array(
        '#markup' => '',
        '#access' => TRUE,
      ),
      'raw' => array(
        'tid' => '28',
        'taxonomy_term' => (object) array(
            'tid' => '28',
            'vid' => '9',
            'name' => '',
            'description' => '',
            'format' => 'filtered_html',
            'weight' => '2',
            'vocabulary_machine_name' => 'affiliation_type',
            'rdf_mapping' => array(
              'rdftype' => array(
                'skos:Concept',
              ),
              'name' => array(
                'predicates' => array(
                  'rdfs:label',
                  'skos:prefLabel',
                ),
              ),
              'description' => array(
                'predicates' => array(
                  'skos:definition',
                ),
              ),
              'vid' => array(
                'predicates' => array(
                  'skos:inScheme',
                ),
                'type' => 'rel',
              ),
              'parent' => array(
                'predicates' => array(
                  'skos:broader',
                ),
                'type' => 'rel',
              ),
            ),
          ),
      ),
    ),
  ),
)

$this->aliases:
array()

I went back into 3.3 and printed $entity_id (line 274). It printed out a 6-digit numerical value, whereas when I did the same for new variable $id in 3.4 with patch #66, it printed blank with dpm or FALSE with dvm.

The 6-digit number corresponds to the value from $this->view->result[0]->og_membership_users_id. That variable (og_membership_users_id) is also the field_alias. Not sure if there is a link there or if it's helpful.

@andrewbelcher Here is the dvm of the same table row from 3.3 with your specifications from #83. It looks like the differences occur with the table array. In 3.3 the table is called og_membership whereas in 3.4 it is views_entity_og_membership. It doesn't look like any of the information from the table is rendered after that in 3.4, but everything is in 3.3.

array(
  'options' => array(
    'id' => 'views_bulk_operations',
    'table' => 'og_membership',
    'field' => 'views_bulk_operations',
    'relationship' => 'og_membership_rel',
    'group_type' => 'group',
    'ui_name' => '',
    'label' => 'OG membership',
    'exclude' => 0,
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'absolute' => 0,
      'external' => 0,
      'replace_spaces' => 0,
      'path_case' => 'none',
      'trim_whitespace' => 0,
      'alt' => '',
      'rel' => '',
      'link_class' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'nl2br' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'more_link' => 0,
      'more_link_text' => '',
      'more_link_path' => '',
      'strip_tags' => 0,
      'trim' => 0,
      'preserve_tags' => '',
      'html' => 0,
    ),
    'element_type' => '',
    'element_class' => '',
    'element_label_type' => '',
    'element_label_class' => '',
    'element_label_colon' => 1,
    'element_wrapper_type' => '',
    'element_wrapper_class' => '',
    'element_default_classes' => 1,
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'hide_alter_empty' => 1,
    'vbo_settings' => array(
      'display_type' => '1',
      'enable_select_all_pages' => 1,
      'row_clickable' => 1,
      'force_single' => 0,
      'entity_load_capacity' => '10',
      'skip_batching' => 0,
    ),
    'vbo_operations' => array(
      'action::views_bulk_operations_delete_item' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_delete_revision' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_script_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_modify_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
        'settings' => array(
          'show_all_tokens' => 1,
          'display_values' => array(
            '_all_' => '_all_',
          ),
        ),
      ),
      'action::og_set_state_action' => array(
        'selected' => 1,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::og_user_roles_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::views_bulk_operations_argument_selector_action' => array(
        'selected' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
        'settings' => array(
          'url' => '',
        ),
      ),
      'action::og_membership_delete_action' => array(
        'selected' => 1,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
      'action::system_send_email_action' => array(
        'selected' => 0,
        'postpone_processing' => 0,
        'skip_confirmation' => 0,
        'override_label' => 0,
        'label' => '',
      ),
    ),
  ),
  'definition' => array(
    'handler' => 'views_bulk_operations_handler_field_operations',
    'click sortable' => FALSE,
    'group' => 'Bulk operations',
    'title' => 'OG membership',
    'help' => 'Provide a checkbox to select the row for bulk operations.',
    'real field' => 'id',
  ),
  'table' => 'og_membership',
  'data' => array(
    'date_argument' => array(
      'group' => 'Date',
      'title' => 'Date (og_membership)',
      'help' => 'Filter any Views og_membership date field by a date argument, using any common ISO date/period format (i.e. YYYY, YYYY-MM, YYYY-MM-DD, YYYY-W99, YYYY-MM-DD--P3M, P90D, etc). ',
      'argument' => array(
        'handler' => 'date_views_argument_handler',
        'empty field name' => 'Undated',
        'is date' => TRUE,
      ),
    ),
    'date_filter' => array(
      'group' => 'Date',
      'title' => 'Date (og_membership)',
      'help' => 'Filter any Views og_membership date field.',
      'filter' => array(
        'handler' => 'date_views_filter_handler',
        'empty field name' => 'Undated',
        'is date' => TRUE,
      ),
    ),
    'table' => array(
      'group' => 'OG membership',
      'entity type' => 'og_membership',
      'base' => array(
        'field' => 'id',
        'access query tag' => 'og_membership_access',
        'title' => 'OG membership',
        'help' => '',
      ),
      'join' => array(
        'node' => array(
          'left_field' => 'nid',
          'field' => 'etid',
          'extra' => array(
            array(
              'field' => 'entity_type',
              'value' => 'node',
            ),
          ),
        ),
        'users' => array(
          'left_field' => 'uid',
          'field' => 'etid',
          'extra' => array(
            array(
              'field' => 'entity_type',
              'value' => 'user',
            ),
          ),
        ),
      ),
    ),
    'id' => array(
      'title' => 'Og membership ID',
      'help' => 'The unique ID of the og membership.',
      'field' => array(
        'real field' => 'id',
        'handler' => 'views_handler_field_numeric',
        'click sortable' => TRUE,
        'float' => FALSE,
      ),
      'sort' => array(
        'real field' => 'id',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'id',
        'handler' => 'views_handler_filter_numeric',
      ),
      'argument' => array(
        'real field' => 'id',
        'handler' => 'views_handler_argument_numeric',
      ),
    ),
    'type' => array(
      'relationship' => array(
        'label' => 'OG membership type',
        'handler' => 'views_handler_relationship',
        'base' => 'og_membership_type',
        'base field' => 'name',
        'relationship field' => 'type',
      ),
      'title' => 'Type',
      'help' => 'Og membership "type" property.',
      'field' => array(
        'real field' => 'type',
        'handler' => 'views_handler_field_machine_name',
        'click sortable' => TRUE,
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'type',
          'view',
        ),
      ),
      'sort' => array(
        'real field' => 'type',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'type',
        'handler' => 'views_handler_filter_in_operator',
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'type',
          'view',
        ),
      ),
      'argument' => array(
        'real field' => 'type',
        'handler' => 'views_handler_argument_string',
      ),
    ),
    'entity_type' => array(
      'title' => 'Entity_type',
      'help' => 'Og membership "entity_type" property.',
      'field' => array(
        'real field' => 'entity_type',
        'handler' => 'views_handler_field',
        'click sortable' => TRUE,
      ),
      'sort' => array(
        'real field' => 'entity_type',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'entity_type',
        'handler' => 'views_handler_filter_string',
      ),
      'argument' => array(
        'real field' => 'entity_type',
        'handler' => 'views_handler_argument_string',
      ),
    ),
    'group_type' => array(
      'title' => 'Group_type',
      'help' => 'Og membership "group_type" property.',
      'field' => array(
        'real field' => 'group_type',
        'handler' => 'views_handler_field_machine_name',
        'click sortable' => TRUE,
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'group_type',
          'view',
        ),
      ),
      'sort' => array(
        'real field' => 'group_type',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'group_type',
        'handler' => 'views_handler_filter_in_operator',
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'group_type',
          'view',
        ),
      ),
      'argument' => array(
        'real field' => 'group_type',
        'handler' => 'views_handler_argument_string',
      ),
    ),
    'state' => array(
      'title' => 'State',
      'help' => 'Og membership "state" property.',
      'field' => array(
        'real field' => 'state',
        'handler' => 'og_handler_field_group_audience_state',
        'click sortable' => TRUE,
        'float' => FALSE,
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'state',
          'view',
        ),
      ),
      'sort' => array(
        'real field' => 'state',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'state',
        'handler' => 'og_handler_filter_group_audience_state',
        'options callback' => array(
          'EntityDefaultViewsController',
          'optionsListCallback',
        ),
        'options arguments' => array(
          'og_membership',
          'state',
          'view',
        ),
      ),
      'argument' => array(
        'real field' => 'state',
        'handler' => 'views_handler_argument_numeric',
      ),
    ),
    'created' => array(
      'title' => 'Created',
      'help' => 'Og membership "created" property.',
      'field' => array(
        'real field' => 'created',
        'handler' => 'views_handler_field_date',
        'click sortable' => TRUE,
        'is date' => TRUE,
      ),
      'sort' => array(
        'real field' => 'created',
        'handler' => 'views_handler_sort_date',
        'is date' => TRUE,
      ),
      'filter' => array(
        'real field' => 'created',
        'handler' => 'views_handler_filter_date',
        'is date' => TRUE,
      ),
      'argument' => array(
        'real field' => 'created',
        'handler' => 'views_handler_argument_date',
        'is date' => TRUE,
      ),
    ),
    'field_name' => array(
      'title' => 'Field_name',
      'help' => 'Og membership "field_name" property.',
      'field' => array(
        'real field' => 'field_name',
        'handler' => 'views_handler_field',
        'click sortable' => TRUE,
      ),
      'sort' => array(
        'real field' => 'field_name',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'field_name',
        'handler' => 'views_handler_filter_string',
      ),
      'argument' => array(
        'real field' => 'field_name',
        'handler' => 'views_handler_argument_string',
      ),
    ),
    'language' => array(
      'title' => 'Language',
      'help' => 'Og membership "language" property.',
      'field' => array(
        'real field' => 'language',
        'handler' => 'views_handler_field',
        'click sortable' => TRUE,
      ),
      'sort' => array(
        'real field' => 'language',
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'real field' => 'language',
        'handler' => 'views_handler_filter_string',
      ),
      'argument' => array(
        'real field' => 'language',
        'handler' => 'views_handler_argument_string',
      ),
    ),
    'etid' => array(
      'title' => 'Entity id',
      'help' => 'Og membership "etid" property.',
      'field' => array(
        'handler' => 'views_handler_field_numeric',
        'click sortable' => TRUE,
      ),
      'sort' => array(
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'handler' => 'views_handler_filter_numeric',
      ),
      'argument' => array(
        'handler' => 'views_handler_argument_numeric',
      ),
    ),
    'gid' => array(
      'title' => 'Group ID',
      'help' => 'Og membership "gid" property.',
      'field' => array(
        'handler' => 'views_handler_field_numeric',
        'click sortable' => TRUE,
      ),
      'sort' => array(
        'handler' => 'views_handler_sort',
      ),
      'filter' => array(
        'handler' => 'views_handler_filter_numeric',
      ),
      'argument' => array(
        'handler' => 'views_handler_argument_numeric',
      ),
    ),
    'og_roles' => array(
      'title' => 'OG user roles in group',
      'help' => 'Show all the roles a user belongs to in a group. Requires a relationship to users to be present.',
      'real field' => 'gid',
      'field' => array(
        'handler' => 'og_handler_field_user_roles',
      ),
    ),
    'og_users_roles' => array(
      'title' => 'OG Roles from membership',
      'help' => 'The OG Roles associated with the OG membership',
      'relationship' => array(
        'label' => 'OG Roles from OG membership',
        'handler' => 'og_handler_relationship_membership_roles',
        'base' => 'og_users_roles',
        'base field' => 'uid',
        'relationship field' => 'etid',
      ),
    ),
    'edit_membership' => array(
      'field' => array(
        'title' => 'Edit link',
        'help' => 'Provide a simple link to edit the membership.',
        'handler' => 'og_handler_field_og_membership_link_edit',
      ),
    ),
    'delete_membership' => array(
      'field' => array(
        'title' => 'Delete link',
        'help' => 'Provide a simple link to delete the membership.',
        'handler' => 'og_handler_field_og_membership_link_delete',
      ),
    ),
    'og_group_ref' => array(
      'group' => 'Content',
      'title' => 'Groups audience',
      'title short' => 'Groups audience',
      'help' => '',
      'field' => array(
        'table' => 'field_data_og_group_ref',
        'handler' => 'views_handler_field_field',
        'click sortable' => TRUE,
        'field_name' => 'og_group_ref',
        'real field' => 'og_group_ref_target_id',
        'additional fields' => array(
          'delta',
          'language',
          'bundle',
          'og_group_ref_target_id',
        ),
        'entity_tables' => array(
          'node' => 'node',
          'node_revision' => 'node',
        ),
        'element type' => 'div',
        'is revision' => FALSE,
      ),
    ),
    'og_group_ref_target_id' => array(
      'group' => 'Content',
      'title' => 'Groups audience (og_group_ref)',
      'title short' => 'Groups audience',
      'help' => '',
      'argument' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_argument_numeric',
        'field_name' => 'og_group_ref',
        'empty field name' => '- No value -',
      ),
      'filter' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_filter_numeric',
        'field_name' => 'og_group_ref',
        'allow empty' => TRUE,
      ),
      'sort' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_sort',
        'field_name' => 'og_group_ref',
      ),
      'relationship' => array(
        'handler' => 'views_handler_relationship',
        'base' => 'node',
        'base field' => 'nid',
        'label' => 'Content entity referenced from og_group_ref',
        'group' => 'Entity Reference',
        'title' => 'Referenced Entity',
        'help' => 'A bridge to the Content entity that is referenced via og_group_ref',
        'field' => 'gid',
        'table' => 'og_membership',
      ),
    ),
    'og_user_group_ref' => array(
      'group' => 'User',
      'title' => 'Group membership',
      'title short' => 'Group membership',
      'help' => 'Appears in: user:user.',
      'field' => array(
        'table' => 'field_data_og_user_group_ref',
        'handler' => 'views_handler_field_field',
        'click sortable' => TRUE,
        'field_name' => 'og_user_group_ref',
        'real field' => 'og_user_group_ref_target_id',
        'additional fields' => array(
          'delta',
          'language',
          'bundle',
          'og_user_group_ref_target_id',
        ),
        'entity_tables' => array(
          'users' => 'user',
        ),
        'element type' => 'div',
        'is revision' => FALSE,
      ),
    ),
    'og_user_group_ref_target_id' => array(
      'group' => 'User',
      'title' => 'Group membership (og_user_group_ref)',
      'title short' => 'Group membership',
      'help' => 'Appears in: user:user.',
      'argument' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_argument_numeric',
        'field_name' => 'og_user_group_ref',
        'empty field name' => '- No value -',
      ),
      'filter' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_filter_numeric',
        'field_name' => 'og_user_group_ref',
        'allow empty' => TRUE,
      ),
      'sort' => array(
        'field' => 'gid',
        'table' => 'og_membership',
        'handler' => 'views_handler_sort',
        'field_name' => 'og_user_group_ref',
      ),
      'relationship' => array(
        'handler' => 'views_handler_relationship',
        'base' => 'node',
        'base field' => 'nid',
        'label' => 'Content entity referenced from og_user_group_ref',
        'group' => 'Entity Reference',
        'title' => 'Referenced Entity',
        'help' => 'A bridge to the Content entity that is referenced via og_user_group_ref',
        'field' => 'gid',
        'table' => 'og_membership',
      ),
    ),
    'og_membership_overview' => array(
      'title' => 'Group membership overview',
      'help' => 'Overview of the group memberships (e.g. group manager, total memebrs).',
      'area' => array(
        'handler' => 'og_ui_handler_area_og_membership_overview',
      ),
    ),
    'draggableviews' => array(
      'title' => 'OG membership',
      'group' => 'Draggableviews',
      'help' => 'Provide a draggable functionality.',
      'real field' => 'id',
      'field' => array(
        'handler' => 'draggableviews_handler_field_draggable',
        'click sortable' => FALSE,
      ),
    ),
    'og_membership_related_node' => array(
      'group' => 'OG membership',
      'title' => 'Node from OG membership',
      'help' => 'The Node entity that is associated with the OG membership.',
      'relationship' => array(
        'entity' => 'node',
        'handler' => 'og_handler_relationship',
        'label' => 'node from OG membership',
        'base' => 'node',
        'base field' => 'nid',
        'relationship field' => 'etid',
      ),
    ),
    'og_membership_related_node_group' => array(
      'group' => 'OG membership',
      'title' => 'Group Node from OG membership',
      'help' => 'The Node group that is associated with the OG membership.',
      'relationship' => array(
        'group_type' => 'node',
        'handler' => 'og_handler_relationship',
        'label' => 'Group node from OG membership',
        'base' => 'node',
        'base field' => 'nid',
        'relationship field' => 'gid',
      ),
    ),
    'og_membership_related_user' => array(
      'group' => 'OG membership',
      'title' => 'User from OG membership',
      'help' => 'The User entity that is associated with the OG membership.',
      'relationship' => array(
        'entity' => 'user',
        'handler' => 'og_handler_relationship',
        'label' => 'user from OG membership',
        'base' => 'users',
        'base field' => 'uid',
        'relationship field' => 'etid',
      ),
    ),
    'og_membership_related_user_group' => array(
      'group' => 'OG membership',
      'title' => 'Group User from OG membership',
      'help' => 'The User group that is associated with the OG membership.',
      'relationship' => array(
        'group_type' => 'user',
        'handler' => 'og_handler_relationship',
        'label' => 'Group user from OG membership',
        'base' => 'users',
        'base field' => 'uid',
        'relationship field' => 'gid',
      ),
    ),
    'views_bulk_operations' => array(
      'title' => 'OG membership',
      'group' => 'Bulk operations',
      'help' => 'Provide a checkbox to select the row for bulk operations.',
      'real field' => 'id',
      'field' => array(
        'handler' => 'views_bulk_operations_handler_field_operations',
        'click sortable' => FALSE,
      ),
    ),
  ),
)

Ok, I've figured out what is going on with that example. Basically the entity field handler for OG Membership on a relationship are broken and fail to load the entities. I'll open a separate issue to resolve that problem. However, there is a very easy work around we can put in the VBO handler and, as we seem to be keen to fix other people's problems, I've attached a patch with that solution in place.

#1928952: views_handler_field_entity sets the wrong base for loading entities is the views issue that is causing the particular OG Membership issue.

@andrewbelcher Thanks so much for your help! Upgrading to 3.4 without any patches and then applying your patch #2 from that Views related issue (mentioned in #91) fixed the problem, whereas applying #90 from this issue caused the problematic tables, as well as some of other Views that use OG membership values to disappear even though there wasn't a VBO field explicitly set and they were not tables. Trying to figure it out but not sure why that happened.

@andrewbelcher After upgrading to 3.4 and applied patch #2. The error is gone ('Please select at least one item' ).
Thanks for the patch. It works for me :)

Just a quick note to add that I was also experiencing this problem with the bulk operations view used by Organic Groups for managing group members, but the patch in comment #90 fixed it (the earlier versions of the patch did not).

The patch in #90 worked for me. But there was an issue when applying the patch. Rerolled it. Thanks!

@smustgrave confirmed patch #95 worked for me. VBO at the latest version with patch, working well with UC order especially.

I spoke too soon, with the latest dev version and applying the patch, clearing caches produced the following log errors:

Base table for Flagging does not have the entity type explicitly set.
Base table for Order does not have the entity type explicitly set.
.....

This actually caused the site to go down until I reverted.

@glynster Try the patch that andrewbelcher posted in #2 on the other related thread for Views (https://www.drupal.org/node/1928952). That is the one that worked for me to fix this problem.

I applied patch #95 against the latest production version (7.x-3.4) and it works like a charm. This was in reference to using VBO on Ubercart orders.

Hi @kjrhody I followed your process #92:

Updated to production v3.4 and applied views patch #2. All log errors and issues went away however in UC order views the issue remains "Please select at least one item."

Am I missing something?

Well... again, what worked for me was applying patch#95 to VBO.
https://www.drupal.org/node/2856944#comment-12138477

I didn't apply the views patch, just the VBO patch above.

@glynster - Hm not really sure. It looks like different patches are working for everyone.. in my case I applied #90 from this thread and it made some of my Views disappear, even if they didn't explicitly have a VBO field set within them. I can try #95 from this thread and see if it works.

But yes, what worked for me originally was to update to VBO 3.4 (also running Views 7.x-3.15 on Drupal 7.52) and then apply #2 from the related views thread mentioned in #91. So doesn't seem like you're missing anything. I wonder why that one didn't work for you.

I applied the patch to VBO 7.-3.4 and did not use the patch for views. And it seems to work fine for me now.

Patch from #95 resolved my problem.
We use VBO to perform custom tasks to Webform submissions.

Is this a good patch that will be committed to .dev/next version of VBO?

I agree with @andrewbelcher in #51. We shouldn't be trying to solve people implementation of views data in the hook_views_data_alter() instead of hook_views_data() and solving that by putting ours at the end, is useful but hacky and could cause more problems than it solves. And the query() override is also not something I'm confident committing.

The patch in #66 minus the views_bulk_operations_module_implements_alter() looks the most commitable. May just need a doc page referencing how to fix the code, or something along those lines to help people deal with their logs. Also HOOK_module_implements_alter may want to be used by the people fixing contrib issues.

Subscribe

#95 worked for me, thanks!

Just following up with the status of this issue? Still seeing this error on some sites.

#106 is the status

I've submitted patches to fix these errors from appearing

https://www.drupal.org/project/fancy_file_delete/issues/2962125

https://www.drupal.org/project/redirect/issues/2962136

https://www.drupal.org/project/views/issues/2962142

This issue just popped up on our site after updating core and other modules. Here's a list of updated modules:

• Drupal 7.58 => 7.59
• devel 7.x-1.5 => 7.x-1.6
• entity_translation 7.x-1.0-rc1 => 7.x-1.0
• file_entity 7.x-2.16 => 7.x-2.20
• i18n 7.x-1.22 => 7.x-1.24
• metatag 7.x-1.22 => 7.x-1.25
• ultimate_cron 7.x-2.5 => 7.x-2.7
• views 7.x-3.18 => 7.x-3.20

The weird thing is, we have run vbo 7.x-3.4 for over a year without any issues.
Now when I try to use vbo for my node views, in hook_action_form(), _views_bulk_operations_get_selection() returns the right value but when I submit the form, $form_state['selection'] is empty and the function returns an empty array.

I tried applying patch #95 and #2 from https://www.drupal.org/project/views/issues/2962142 but without success.

I have been using with success the same patch as in #95 minus the "query" part on 40+ sites without any problem on 3.4 for over a year using vbo with commerce, ubercart, users, nodes, registrations, etc... I also believe that the attempt to fix the OG Membership problem with the query part should be worked on separately.

While I agree that this patch may fix other modules problems. They were not issues with vbo before 3.4. So, in my point of view, we are fixing a problem "created" by vbo 3.4+. In a perfect world, it would be best to have all other modules fixing their problems but I do not think it is realistic. Better fixing it ourselves if we can. No? The patch is so simple, what are the real life risks?

I also believe it is important to take into account that vbo 3.4 and 3.5 without this patch, completely break all your views using entities not "properly declared" for vbo. Which is why I am putting the priority of this issue to major. People should be aware of that fact. Sorry if it should have stayed normal.

Also, since this patch fixes the majority of the issues created by vbo 3.4/3.5, I do not see the point of having the watchdog polluting the system logs. Since already fixed most of the time, they are kind of false positives anyway. That is why I comment it out personally but I left it in my proposed patch.

To the maintainer : Please consider the importance of this issue. It would be really nice having it reviewed again and this patch committed if you deem it reasonable.

Thank you all for your time on this, we love VBO!

As I asked in #106 Why is this needed? views_bulk_operations_module_implements_alter() it could cause more issues if other modules are also trying to be at the end and could cause more issues than it solves.

I am getting this message after updating 3.4 to 3.5. Now I am happy to not be on 3.4 since it was very buggy, hopefully this can be resolved for 3.6 :)

@joelpittet The hook_module_implements_alter() was discussed in #47 and introduced in the patch in #51.

It was specifically for better_watchdog_ui and it is not needed anymore in VBO when applying the patch for better_watchdog_ui available there : https://www.drupal.org/project/better_watchdog_ui/issues/2856723#comment...

This patch was committed in 7.x-3.x-dev of that module : https://www.drupal.org/project/better_watchdog_ui/releases/7.x-3.x-dev

So I completely agree that we only need the first part of the patch in VBO to fix this here for good :

+++ b/views/views_bulk_operations.views.inc
@@ -17,6 +17,10 @@ function views_bulk_operations_views_data_alter(&$data) {
           'click sortable' => FALSE,
         ),
       );
+      // Check that the base table has the entity type key set.
+      if (!isset($data[$info['base table']]['table']['entity type'])) {
+        $data[$info['base table']]['table']['entity type'] = $entity_type;
+      }

I re-rolled the patch against current dev.

Thank you.

Would you mind removing views_bulk_operations_module_implements_alter() from #113? And I'll happily commit that change, just don't want to commit the change without a bit of agreement, thanks

Sorry forgot to attach the patch... :-)

Thank you @LeDucDuBleuet I've committed that to the dev branch.

Great! Thank you very much!

Hopefully, we'll have a 3.6 release soon. :-)

+1 for a release with this (3.6)
thanks a bunch, great work!

+1 for new release (3.6) with this in. Thanks.

The committed patch doesn't fix the issue for a webform submissions view which worked in 7.x-3.3

The specific update in 7.x-3.4 that causes the issue is in views_bulk_operations_handler_field_operations.inc:

- $entity_id = $this->get_value($row);
+ $this->view->row_index = $row_index;
+ $id = $this->get_value($row, $this->real_field);

when the second parameter is passed to get_value() an empty result is returned

+1 to release it!

@ashlewis Just to clarify, in #125 are you suggesting a patch to reverse the change to views_bulk_operations_handler_field_operations.inc in 7.34? Is this in addition to the the patch in #118 that was committed or is that patch not needed with the change you suggest? Thanks.

@izmees The code added in #118 never actually gets hit for my webform submissions view, so has no effect in this scenario.

After another look, it seems it's nothing to do with the second parameter being passed to $this->get_value($row, $this->real_field) either, but apparently something else (in the 7.33 -> 7.34 update) that is causing get_value method to return FALSE.

Here's a patch that fixes the issue i was having with webform submissions. Caveats: Firstly, it seems to me to be pretty ugly OOP style, and i'm also not sure if this could have any implications in other situations.

SORRY - while this appeared to fix the issue, the selected content was not actually being updated :-(

If anything, the method should have not passed the $field param to get_value():
- return parent::get_value($values, $field) ?: views_handler_field::get_value($values, $field);
+ return parent::get_value($values, $field) ?: views_handler_field::get_value($values);

but this still did not work - i'll keep digging.

Hi Joël (@joelpittet),

In #119, which patch, or combinations of patches, solves this issue when applied against 7.x-3.5? I need to patch a production site and I'd rather not guess :(

Thanks,
Michael

PS: Also, wouldn't issues stay open until their fix is released under a production rev.? Or maybe I'm confusing Drupal's methods with other open source projects' methods? Not really a biggie I guess...

I'm also still experiencing this bug, even on 7.x-3.x-dev with this update. I've opened #3078514: Cannot delete items, 'Please select at least one item' error as a followup. Does anyone know of any workaround?

Did anyone solve this issue for VBO?:

No operation selected. Please select an operation to perform.
Please select at least one item.

It is essential to the site. Tried VBO 3.3 3.4, using 3.5 currently and tried dev too. Same error.

Many thanks in advance to anyone who might have a lead on it.

Yves

It's still an issue -- we're hoping a fix comes out and in the meantime remain on version 7.x-3.3 of VBO. You're not alone.

Hi Tom,

Thanks for letting me know, much appreciated.

I still have the error, tried 7.x-3.3, nothing seems to work. If anyone has a guide to where to look for a clue to the fix??

The patch in comment #118 is all you need to solve this issue and it has been committed to the dev branch.

I have been using version 3.5 with the patch in #118 since may 2018 with success on multiple websites.

I'm hiding the patch in #129 since it does nothing to solve this issue according to the submitter ashlewis.

If you still have this issue even with the patch in #118 on 3.5 or using the dev version, it must be coming from somewhere else in one of your module.

HI,

Thanks. I did try the dev version and that did not work and just installed new update VBO 3.5 (did you mean 3.4 in May 2018?) and neither does that (have not tried the patch). This has error has now spread to my other Drupal sites. So the only thing I can think of is it is due to the update of another module. But no idea how to find out which one. Thanks for the info though on the patch.

Hi
This does not look like fixed, after updating core and modules on an old site got this error with v7.x-3.6 and Development version: 7.x-3.x-dev updated 9 Sep 2020 at 22:26 UTC.
Need to roll back to v7.x-3.3

@hatuhay

it's possible you have multiple copies of this module in your filesystem

run the duplicate module fixer module to find all the versions of this module that are on your site.

please try again with version 3.6 eliminating duplicate copies of older versions using dmf

This might help figure out what is going on.

Hi, I'm still seeing this with 7.x-3.6

It appears as though all the patches are applied, the patch in #118 has been released and on checking the `views_data_alter` hook I'm seeing the `entity type` key is set correctly.

I'm using this with Organic groups. If I create a view of users, add a relationship `OG membership: OG membership from User` and add a VBO field on membership, the `value` attribute in the resultant views form is empty in the markup. This affects the organic groups members admin view on my site. I'll post something similar for OG to have a look and link back to this issue.

As a test I created another view of users, added a relationship to comments authored and then added a VBO field for the comment, with the same result. The value attribute in the markup for the checkbox is empty, so nothing works. As users and comments are core modules, there does seem to still be a problem in VBO.

Finally. I tried reverting my project to VBO 3.3 but that results in a broken handler in views so I can't go back.

Help would be much appreciated.

@darksnow , might be worthwhile checking out the OG issue queue or the views issue queue for organic groups related issues that might somehow resolve this for you. what version of OG are you using? what version of php ? what version of db/ flavour? mysql/mariadb/postgres ? which version of db? what version of core?