Feature implementation of roles/permissions is broken

@kristiaanvandeneynde,
What Features version are you using?

> The patch was made git aware, so please provide credit as per Adding a commit author by using 'git am'.

Yes, this is the standart in OG's queue :)

Coming from background using features d6 a lot, my guess is there's a bug in rebuild vs not having enable implemented.

To expand on above ,og_features_role_features_export_render should not render a role that is in code but not in the database. It basically exporting non-existent roles

/**
 * Implements hook_features_export_render().
 */
function og_features_role_features_export_render($module, $data) {
  $code = array();
  $code[] = '  $roles = array();';
  $code[] = '';

  foreach ($data as $name) {
    list($group_type, $bundle, $rolename) = explode(':', $name);
    $role = array(
      'gid' => 0,
      'group_type' => $group_type,
      'group_bundle' => $bundle,
      'name' => $rolename,
    );
    $role_identifier = features_var_export($name);
    $role_export = features_var_export($role, '  ');
    $code[] = "  // Exported OG Role: {$role_identifier}.";
    $code[] = "  \$roles[{$role_identifier}] = ${role_export};";
    $code[] = "";
  }

See, nothing checks if the role exists and it exports using the info from $data

#1: og-feature-implementation-broken-1920342-1.patch queued for re-testing.

@hefox: I think that what you noticed should be seen as a different bug.

I experience the same problem as kristiaanvandeneynde for roles which have no permissions set. Roles with permissions are imported fine.

The patch in #1 looks fine and does indeed fix the problem.

Ho stop! Hold the presses. I'm experiencing some problems with OG Permissions / Features. Finding out whether is it due to the above patch or not right now.

To be a bit more arrogant/forceful. The enable hook should not be needed. None of the other "faux" exportables need it, why would og_permissions? I could be wrong of course, but I am one of the comaintainers of features; I know most of features code in and out, (at least when it comes to the revert/rebuild and faux exportables).

Guessing, but this does seem possible more likely a features bug than og.

@hefox: you're right. I just looked at the features support for roles/permission in the features itself and it doesn't use that either. I now have a hunch that the problem is with the order of importing, but I'm looking a bit further into that to be sure. But indeed, the patch in #1 is not the right solution.

By the way. I've posted a patch for your point in #8:
#2021673: [Features] Do not export non-existing roles.

@kristiaanvandeneynde: The feature claimed to be in 'Default' state because og_features_role_features_export_render() did not check whether the roles exists in the database. A new export would therefore not differ from the current state of the feature, even when creating the role failed. The patch I mentioned in #14 fixes that.

Apart from that, Features might try to set permissions before they even exist. I assume this is what the patch in #1265168-38: Rebuild the file list properly when a feature is enabled or disabled fixes? (correct me if I'm wrong.)

I've just tested the combination of #1265168-38 with the patch I mentioned in #14 and this also solves the problem.

@kristiaanvandeneynde: Thank you, I've read it before but still find it hard to get a good grip on what is happening in that issue.

Anyway. I've done quite some testing now and I believe that apart from that bug in features and the issue hefox addressed in #8, there is no other problem. In retrospect, opening a new issue for that problem was not needed. But since that is now done, would anybody disagree with closing this issue in favor of #2021673: [Features] Do not export non-existing roles. ? (or else close that one as a duplicate of this issue.)

From what I understand, this should be closed in favor of the features issue.