Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm testing the upgrade path from 7.x-1.x to 7.x-2.x, using rc3. I've run the migrations however I'm getting Access Denied errors when I try to access /[bundle]/[entity]/[entity_id]/admin/people and other similar OG admin pages. I also get Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of includes/common.inc). when attempting to access admin/config/group/permissions/[entity]/[bundle]
This is similar to the issues reported here: http://drupal.org/node/1868428
I've worked my way through the code and it appears these errors are caused by there being no group roles post-migration. The db table og_role is empty.
Prior to migration, we had the default non-member, member and administrator member roles as well as two additional custom roles. The table og_roles contained these rows prior to the upgrade.
I think part of the issue is that the migration OgMigrateRoles shows 0 total rows, 0 unimported and 0 imported. It is therefore doing nothing. The other part of the issue is that the og_roles table has been wiped and therefore records of both the default and our custom roles no longer exists.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1898222-og-migrate-role-empty.patch | 926 bytes | mradcliffe |
| #2 | Ignore_dependencies_screenshot.png | 132.06 KB | vermario |
Comments
Comment #1
torrance123 CreditAttribution: torrance123 commentedLooking into this further, I can see that you're doing some migration work in a
preImport()method. If there were a non-zero number of rows to import, I imagine this would work fine. But if the total rows are 0 then the migration won't ever be run, andpreImport()will never be called. OGMigrateUserRoles will then be run under the assumption that OGMigrateRoles has been completed.The work around here is to manually fire each of the OG migrations in the correct order that than selecting them, even if 'total rows' for an import is 0.
But obviously something more robust is needed to ensure that
preImport()in OGMigrateRoles is fired.Comment #2
vermario CreditAttribution: vermario commentedI was in the same situation (0 records shown in the "OgMigrateRoles" row). And I got the same symptoms. I managed to get a bit further by executing the migrate operation by itself, specifying the "Ignore dependencies" checkbox in the "Options" fieldset. (See screenshot).
Comment #3
BrightBoldSame as @vermario — Ignore dependencies solved the problem for me. I think in my case OgMigrateMemberships was falsely reporting failure; someone else reported in an issue that I now can't find for the life of me (even though I swear I commented on it!) that the number of rows reported was greater than the actual number of rows, so Migrate was saying some rows hadn't been migrated when in fact they all had. I'm hoping this explains my situation. But whether or not I have 6 unmigrated memberships, "Ignore dependencies" did allow me to proceed and got rid of the errors reported above.
Comment #4
torrance123 CreditAttribution: torrance123 commentedMaybe that was another ticket I posted? http://drupal.org/node/1898326
Comment #5
BrightBoldYes, thanks! I guess I didn't save my comment, but that was it.
Comment #6
amitaibuComment #7
forsythes CreditAttribution: forsythes commentedOptions > Ignore Dependencies didn't seem to work for me. The problem that I'm having with OgMigrateRoles is that it keeps telling me 0 rows, 12 imported, and -12 unimported. Now, I'm not sure what -12 unimported means, but I can tell you that my gids all changed in my og_role table and that there are now absolutely no users assigned to any OG roles when I go into the groups themselves to see who is the administrator for that groups. Any ideas?
Comment #8
mradcliffeI am not sure what issue this is a duplicate of as the only linked issue does not have anything to do with OgMigrateRoles class.
I encountered this issue in my first test run of Og1 -> 2 migration. I clicked on OgMigrateRoles to inspect the mapping, and I noticed that the name field wasn't mapped. After adding name to the ogr.name and a corresponding fieldMapping, I did not have the issue.
Comment #9
amitaibuSince we are updating existing rows, the name should stay -- so the above patch seems wrong. What am I missing?