Include role_export in Panopoly

I'm definitely for this. We use role_export in every other platform that we manage. I was surprised it wasn't in Panopoly already but maybe there was a reason?

We would need to check if we reference roles by their numerical ID anywhere and update the references, since once you assign a machine name, the numerical ID's of each role will change (they are calculated automatically based on the machine name).

One way to do this without requiring panopoly_core as a dependency in panopoly_admin would be to implement hook_strongarm_alter(), and in that hook use module_exists() to check if panopoly_core is enabled and if so, alter the value of the user_admin_role variable. However, doing so would result in the feature appearing as overridden since Features doesn't properly handle defaults_alter hooks yet and reports them as overriden even if the override is implemented via alter hooks. Plus, what we have there currently references the rid '3' - which is completely meaningless so changing it to '30037204' isn't any worse. With that in mind, I think we could get away without introducing the dependency on panopoly_core, though I have no idea if anyone is actually using panopoly_admin it without also using panopoly_core. Usage stats show:

panopoly_admin: 2,136
panopoly_core: 2,363

Also, I can see one other places where role ids are referenced in the code:

panopoly_widgets.views_default.inc:187

  $handler->display->display_options['filters']['type']['expose']['remember_roles'] = array(
    2 => '2',
    1 => 0,
    3 => 0,
    4 => 0,
  );

Also, what is the logic behind using the panopoly_ prefix for the editor role, but not for the administrator role?

I haven't tested this yet, and while I'm in support of role_export in general, I'm worried about upgrading existing sites.

After upgrade, will there now be two 'administrator' roles: one with the rid 4 and the other with an rid of 30037204? How will this affect other things that store the old rid like Rules, Views, etc some of which may been created by the site builder (ie. not the distro)?

Given the number of possible things that can store rid, I don't think we can do an automatic conversion from the old rid to the new...

I'm marking this as postponed on plans for a Panopoly 2.x, since the upgrade path would be problematic: #2334091: Panopoly 7.x-2.x hitlist

Could this be reconsidered. Read this and this might help on the upgrade path? https://drupal.psu.edu/blog/post/d7-features-secret-rolemageddon

That's a pretty sweet patch! And I think it's the start of a partial solution to this problem. However, even if it handled 90% of all contrib modules, I still would rather not add role_export for Panopoly 1.x because it's meant to be stable.

If we end up doing a 2.x branch for Drupal 7, this is the first thing we should commit. :-) But my focus personally is going to be on getting Panopoly 1.x into maintanence mode, and working on Panopoly 2.x for Drupal 8.