Given that for a Drupal to Drupal migration (at least since Drupal 5), we can assume roles 1 and 2 are the default two (anonymous user, authenticated user), we just need to rebuild the roles table with the correct role ID to role name mapping. While it is easy to manually move the data from the D5 or D6 table to the D7 one, if we're serious about replacing the Drupal update mechanism with Migrate, this has to work.

I think this is most of the way there, given the existence of the MigrateDestinationRole class and the fact that the Users migration also handles the users_roles mappings. The problem I'm currently working on is a scenario in which 6 roles have been created in addition to the default two, and then one of those roles has been deleted, leaving a role ID gap; when I attempt to use the MigrateDestinationRole class, it seems to auto-increment the role ID rather than create the role name mapped to the existing role ID. Since the users_roles table includes the role ID, when re-creating permissions, it is helpful if the roles don't get shifted by one ID, since this gives the administrator role to the wrong Role ID, and thus to the wrong users; we don't want to accidentally give users more privileges than they should have.

It's entirely possible I have a bug in my implementation of MigrateDestinationRole; I'm working on a D5 to D7 migration right now, so if I get the role migration working, I'll update here.

Comments

SamH’s picture

SamH commented

Well, rid is an AUTO_INCREMENT field, so I don't see how you'd override that and ensure that role names keep the same IDs.

Instead, I would make MigrationDestinationUser dependent on MigrationDestinationRole, and have it use your Role migration as the source for roles. For example, from migrate_example/wine.inc, lines 318-320:

    $this->addFieldMapping('roles', 'positions')
         ->separator(',')
         ->sourceMigration('WineRole');

The example imports from a CSV; coming from D5, I don't think you'll need the separator.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Right, the role IDs will not be maintained - there's no need to, any more than there's a need to maintain the same nid on node migrations. Migrate will maintain the relationship between the old role ID and the new role ID in the migrate_map table, and as Sam points out you use the sourceMigration so the right role ID gets assigned on the destination side.

hackwater’s picture

hackwater commented

SamH, mikeryan: Thanks for pointing me to sourceMigration; it looks like that will do exactly what I'm looking for. I'm hoping for a spare moment next week to try this out with my sample Drupal 5 site, and I expect I'll be reporting back with a successful migration. I believe sourceMigration and the user -> role dependency should also work for Drupal 6 -> 7 migrations, but I'm nowhere near ready to do that particular site.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Assigned: Unassigned » mikeryan
Status: Active » Fixed

Finally done. You can add a "role_mappings" argument when registering a role migration if you want an old role to be mapped to a new role, e.g.:

    $arguments['role_mappings'] = array(
      'Fan Club' => 'fan club member',
    );

would mean that instead of creating "Fan Club" as a role in the destination site, anyone who had the "Fan Club" role in the source site will be assigned the "fan club member" role in the destination site.

Also note that you should add a role_migration argument (value would be the role migration machine name) to your user migration so it will map the role assignments.

Status: Fixed » Closed (fixed)

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