Steps to reproduce:

1. Download and enable webforms from 4.1.
2. Disable, but do not uninstall webforms.
3. Download webforms 4.2 but do not enable it still.
4. Attempt to run a database update.

What you should see is a SQL error:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null [error]

After some digging of my own, I determined that it is intended behaviour for disabled modules to run update hooks (see http://www.drupal.org/node/194310) and probably a reason why they advise caution when relying on hooks in update hooks (see hook_update_N). This error happens because, in user_role_grant_permission(), the module of the permission is looked up using user_permission_get_modules() which only uses enabled modules to build the permission list.

The simplest solution I can think of is to verify that webform is enabled before running the update hook, but then if webform is enabled again later, it won't have the permission granted properly. An alternative would be to bypass user_role_grant_permission() and insert the permission directly into the database with the proper module. I can write a patch for either of these, just need some direction.

For those looking for a workaround, you can enable webform, do the update, and then disable it again.

Comments

DanChadwick’s picture

Status: Active » Closed (works as designed)

Uh, don't do that. :)

The assumption, I believe for all modules, is that the install, enable, disable, update, and uninstall hooks are run on a consistent database. In other words, you cannot change the code base out from under the database, or vice versa.

The issue with hook_update_N is specifically related to schema, which in the future could be quite different than when the update routine was written. This is not the same issue.

I don't think this issue is unique to webform, but rather a broader issue and outside the scope of this issue queue.