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
Comment #1
indytechcook CreditAttribution: indytechcook commentedI added a bean_reset before the bean_get_types() call in bean_permission. try that.
http://drupal.org/commitlog/commit/22232/11a304fd1cc6482f1e3e34801c9de7a...
Comment #3
Taz CreditAttribution: Taz commentedStill 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?
Comment #4
saltednutJust throwing bean_reset() on stuff is a bad idea. Nearly posting an issue about Bean::save(); soon...
Comment #5
sherakama CreditAttribution: sherakama commentedI was able to get the feature module to install with a little work around. The steps are pretty much as such.
New file at: [my_bean_feature_module]/plugins/bean/FeatureBean.inc
this file contains only:
Then in hook_bean_types() "my_bean_feature.module":
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:
This allows for the feature module with the bean types in it to install and does not effect the bean's fields or views.
Comment #6
DamienMcKennaIt's a known problem for a lot of other modules too, e.g. #1549608: Cannot import exported Panelizer permissions using Features/defaultconfig if handler cache is stale.
Comment #7
sherakama CreditAttribution: sherakama commentedMy 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
Comment #8
dxvargas CreditAttribution: dxvargas commentedI can't replicate this problem. Steps:
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.