I'm making upgrade tests from my D6 site to D7 in test environment and I'm having an issue after installing content access module.

Description of the setup and upgrade steps, can be reproduced on my environment

  • Upgraded Drupal core from 6.24 to 7.14 without errors
  • Migrated all my CCK fields without errors
  • Upgraded ACL module (7.x-1.0) + update.php + rebuild permissions, without errors
  • Upgraded Content Access module (7.x-1.2-beta1) --> no errors.
  • Run update.php after enabling Content Access --> no updates available.
  • Rebuilt permissions --> got the error message displayed below.

The error message that I get when rebuilding the permissions after enabling Content Access is as follows:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /fi/batch?id=762&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'author' for column 'gid' at row 1: INSERT INTO {node_access} (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5), (:db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11), (:db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17), (:db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23); Array ( [:db_insert_placeholder_0] => 2028 [:db_insert_placeholder_1] => content_access_rid [:db_insert_placeholder_2] => author [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 1 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 2028 [:db_insert_placeholder_7] => content_access_rid [:db_insert_placeholder_8] => 36 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 1 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 2028 [:db_insert_placeholder_13] => content_access_rid [:db_insert_placeholder_14] => 3 [:db_insert_placeholder_15] => 0 [:db_insert_placeholder_16] => 1 [:db_insert_placeholder_17] => 0 [:db_insert_placeholder_18] => 2028 [:db_insert_placeholder_19] => all [:db_insert_placeholder_20] => 0 [:db_insert_placeholder_21] => 1 [:db_insert_placeholder_22] => 0 [:db_insert_placeholder_23] => 0 ) in node_access_write_grants() (line 3417 of /path/to/modules/node/node.module).

The site in question was originally built on Drupal 5 and upgraded to Drupal 6. The Drupal 6 version of the site works like a charm without any problems. However, I suspect that there is something strange in the access control tables that is causing this problem to occur. The site is rather large and has 46 roles in addition to authenticated / anonymous users. The roles are quite simple, there is one role for each club that have access control rules applied for their own club content etc.

Other ACL modules that are enabled on the D6 site (but not upgraded in my D7-tests yet) include Forum Access and Node Access Node Reference.

Does the error message give any hints about what could be wrong on my ACL tables? What is the record 2028 that occurs in the error message? In theory it is possible (yet requires a lot of coffee) for me to wipe out all access control rules from the D6 site and then re-define the correct permissions to all roles on the D7 site after upgrading if we suspect that there are some ghosts in the ACL tables.

Please give me some suggestions what would be the next steps for troubleshooting this, I'm more than happy to provide my input for the community and help troubleshooting these kind of corner cases.

Markus

Comments

masipila’s picture

Just tested the following workaround which works OK:

- Uninstalled Content Access on the D6 site
- Upgraded Drupal core from 6.24 to 7.14 without errors
- Migrated all my CCK fields without errors
- Enabled ACL module (7.x-1.0) + Content Access module (7.x-1.2-beta1) + update.php + rebuild permissions, without errors

Of course I must now define all content access rules manually but that is doable.

If somebody wants to investigate this further please let me know. As mentioned in the original post, this can be reproduced with my site and I'm willing to troubleshoot this further if needed.

Cheers,
Markus

bjorpe’s picture

same issue - subscribing

Triskelion’s picture

I ran into the same problem upgrading to D7 (Site has been running fine in D6 after an upgrade from D5).

Since the node_access table is unchanged D6 to D7 I simply repopulated it from the D6 database, and access permissions were restored. However the error persisted when a rebuild was attempted. In my case it was node 1, not 2028. Definitely a D5 issue, tolerated by D6. When I looked at the D7 database, I returned several records using the queries:

SELECT * FROM content_access WHERE settings like "%author%";
SELECT * FROM variable WHERE name like "%content_access%" AND value LIKE "%author%";

eg: content_access_page a:5:{s:4:"view";a:6:{s:6:"author";s:6:"author";i:3;i:3;i:1;i:1;i:2;i:2;i:4;i:4;i:6;i:6;}s:6:"update";a:3:{s:6:"author";s:6:"author";i:3;i:3;i:6;i:6;}s:6:"delete";a:3:{s:6:"author";s:6:"author";i:3;i:3;i:6;i:6;}s:8:"per_node";i:1;s:8:"priority";s:1:"0";}

A little more digging, and I found that D5 used rid = 'author', which was supposed to be fixed with the upgrade content_access_update_6001(). I returned to my D6 site and re-ran 6001 with update.php, and the content_access_settings variable remained unchanged (still the same as the D5 value).

So this issue may be summarized as a failed D5->D6 upgrade, which was tolerated by D6 but blows up in your face when upgrading from D6 to D7. Please fix this for the benefit of your faithful users since the D5 version who are now facing D6's end-of-life.

japanitrat’s picture

Hm... can this be done manually, afterwards, maybe?

mvc’s picture

This happened to me too on a site upgraded from D5 to D6 to D7, when I attempted to enable per-node access permissions for a content type. If you see any results when running the queries Triskelion listed above, you'll likely have the same problem.

The simplest way to fix this is to delete all the database rows returned by those queries. The entries in the variables table control the per-type settings (eg. admin/structure/types/manage/webform/access) and the entries in the content_access table control the per-node settings (eg. node/123/access). After manually deleting entries for those types and/or nodes you'll need to edit the access settings for each type and node and save the page again (even if you just want to use the default settings). You should then rebuild the node access settings.

I realize that this process potentially removes a large number of custom settings but that was acceptable for my use case so I didn't investigate further into correctly migrating the D5 settings to D7.

gisle’s picture

Version: 7.x-1.2-beta1 » 7.x-1.x-dev
Priority: Major » Normal
Status: Active » Closed (outdated)

This issue has not received any updates in the previous 6 years. If you believe it to still be relevant, you are encouraged to reopen the issue and update it.

If you got an email about this Issue status update, it is because you at one time (possibly a very long time ago), subscribed to it. To learn how to unsubscribe yourself, please visit: https://www.drupal.org/project/webmasters/issues/3142987