Once upon a time someone who loved Bean and Features tried to use them to build a reusable component for its future developments.

He created a very simple Bean Type including a few Fields then he checked and granted the permissions related to this Bean Type to its Roles. After processing some tests, he was fully satisfied and very impatient to package all this into a Feature.

But here is where the story turn dark.
Once the Feature properly generated, our valorous developper had to try it on a clean Drupal install. Using drush like a great warrior, the developper tried to enable the Feature but a monstruous beast called PDOException defeated him.

WD php: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES
(:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 1
    [:db_insert_placeholder_1] => view any simple bean
    [:db_insert_placeholder_2] =>
)
 in user_role_grant_permissions() (line 3054 of [path-to-drupal]\modules\user\user.module).

What happened was that when the Feature tried to set the exported permissions for the Bean Type, the bean_fetch_plugin_info function lied when she listed the existing plugins because she was stuck in a drupal_static and cache_get web. The bean_permission function returned a permission list not including the new Bean Type's ones.

The defeated developper tried a lot of workarounds like calling bean_reset just after the bean_type component of the Feature was reverted, but without any success. After hours and hours trying to beat the Beast, our hero decided to ask for some help to its great community.

What happened next is up to you, but our hero will stay here if you need more details.
Cheers.

Comments

indytechcook’s picture

Status: Active » Fixed

I added a bean_reset before the bean_get_types() call in bean_permission. try that.

http://drupal.org/commitlog/commit/22232/11a304fd1cc6482f1e3e34801c9de7a...

Status: Fixed » Closed (fixed)

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

Taz’s picture

Status: Closed (fixed) » Needs work

Still exists on latest version
bean_reset() did not fix completely. module value is still missing on insert of role_permission

Should the weighting of this module be higher?

saltednut’s picture

Just throwing bean_reset() on stuff is a bad idea. Nearly posting an issue about Bean::save(); soon...

sherakama’s picture

I was able to get the feature module to install with a little work around. The steps are pretty much as such.

  1. Create an empty custom plugin class
  2. Add hook_bean_types to my_bean_feature.module
  3. Create plugin entries using information found in the exported my_bean_feature.bean.inc
  4. Add hook_ctools_plugin_api() entry for bean types

New file at: [my_bean_feature_module]/plugins/bean/FeatureBean.inc
this file contains only:

<?php
/**
* @file
* This file is here so we can install the feature module.
*/
class FeatureBean extends BeanPlugin {
}

Then in hook_bean_types() "my_bean_feature.module":

my_bean_feature_bean_types() {
  include_once "my_bean_feature.bean.inc";
  $plugins = array();
  $types = my_bean_feature_bean_admin_ui_types();
  $plugin_path = drupal_get_path('module', 'my_bean_feature') . '/plugins/bean';

  foreach($types as $k => $bean_type) {
    $plugins[$k] = array(
      'label' => $bean_type->name,
      'description' => t($bean_type->description),
      'handler' => array(
        'class' => 'FeatureBean',
        'parent' => 'bean',
        'path' => $plugin_path,
        'file' => 'FeatureBean.inc',
      ),
    );
  }

  return $plugins;
}

You should also have an exported my_bean_feature.features.inc file. In there should include a ctools_plugin_api(). It should have the following two entries:

function my_bean_feature_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "bean_admin_ui" && $api == "bean") {
    return array("version" => "5");
  }
  if ($module == "bean" && $api == "types") {
    return array("version" => "5");
  }
}

This allows for the feature module with the bean types in it to install and does not effect the bean's fields or views.

DamienMcKenna’s picture

sherakama’s picture

My comment from 1 year ago has changed a bit. If you want to see a working example you can dig through this module: https://github.com/SU-SWS/stanford_bean_types

dxvargas’s picture

I can't replicate this problem. Steps:

  1. Create a bean type
  2. Export all bean permissions into a new feature
  3. Comment line introduced in commit in #1 - the call to bean_reset(TRUE); in bean_permission()
  4. Re-install Drupal and enable the feature - OK
  5. Re-install Drupal with the feature as a dependency in profile- OK

Can someone give more insight about what is needed to get the error?
I would like to work on a solution for this and close it.
Like @Taz and @brantwynn told just throwing a bean_reset may not be a good solution.