Role sharing

Actually, the idea was to be able to have distinct sets of roles for different sites.

In principle it should be easy to add the role IDs/ Names to the cookie, though.

Perhaps a variant of this would be to allow the master site to control the roles for which bakery login is allowed. For example, this would allow an admins subsite made up only of whose with the role 'admin' on the master site.

I for one would find this very useful, and I suspect it could be used on d.o. for those subsites where the access is controlled to members of specific teams.

subscribe

I agree that would make sense to implement this. The only problem I can see with this is when the roles in the sub-domain is not the same of the master domain. I think this is the case of groups.drupal.org where (if I understood what greggles wrote) there isn't the role site maintainer but the role editor.

Considering that, and the fact there would be reasons to not allow the same roles in a sub-domain, it makes more sense to have a setting page for the sub-domain, where the administrator of the sub-domain can decide how to map the Drupal.org role into the sub-domain role (and choose to not apply any mapping, in the case he prefers so).

I'd like to propose #556666: Sync hooks: Enable sharing of arbitrary data for this. Perhaps Bakery could invoke the sync hook on behalf of the user module. Another module could also implement the hook and provide it's own screens for defining the mapping.

Here's two snippets that would work in a test.module when Bakery has the sync hook patches applied from #556666: Sync hooks: Enable sharing of arbitrary data.

This assumes role IDs are the same, which is obviously not acceptable. But, the test module on the slave side could have a map from master RIDs to slave RIDs.

/**
 * Implements hook_bakery_transmit().
 */
function test_bakery_transmit($edit, $account, $category) {
  $roles = array();
  // Check if roles are changing and
  // Set which role names to add or remove.
  foreach ($edit['roles'] as $rid => $set) {
    if (isset($account->roles[$rid]) && !$set) {
      // Removing role from account.
      $roles[$rid] = $set;
    }
    elseif (!isset($account->roles[$rid]) && $set) {
      // Adding role to account.
      $roles[$rid] = $set;
    }
  }
  return !empty($roles) ? array('roles' => $roles) : array();
}

/**
 * Implements hook_bakery_receive().
 */
function test_bakery_receive($account, $fields) {
  if (isset($fields['roles'])) {
    $roles = $account->roles;
    foreach ($fields['roles'] as $rid => $set) {
      if (isset($account->roles[$rid]) && !$set) {
        // Remove role.
        unset($roles[$rid]);
      }
      elseif (!isset($account->roles[$rid]) && $set) {
        // Set role. Value doesn't matter.
        $roles[$rid] = $rid;
      }
    }
    user_save($account, array('roles' => $roles));
  }
}

Here's an updated test receive implementing rollback! http://drupal.org/node/556666#comment-2932078

function test_bakery_receive($account, $fields) {
  if (isset($fields['roles'])) {
    $roles = $previous = $account->roles;
    foreach ($fields['roles'] as $rid => $set) {
      if (isset($account->roles[$rid]) && !$set) {
        // Remove role.
        unset($roles[$rid]);
      }
      elseif (!isset($account->roles[$rid]) && $set) {
        // Set role. Value doesn't matter.
        $roles[$rid] = $rid;
      }
    }
    $status = user_save($account, array('roles' => $roles));
  }
  if ($status) {
    return TRUE;
  }
  else {
    // Roll back.
    $status = user_save($account, array('roles' => $previous));
    return FALSE;
  }
}

I think this makes a ton of sense. I'm not sure how to do role mapping in a generalized way :/ I guess you create a tiny database table and CRUD for it? or require an array in settings.php?

Implementing hooks on behalf of core modules is commonly done in contrib and this is another case where it makes sense.

Another piece of evidence that says numeric keys are problematic. If we had machine names for roles this would be easier. And it would make roles easier to export as "exportables".

Is there a core issue for this that we could participate in?

I would also like this feature -> subscribe

A slightly different array structure than #7 and #6 worked for me.

Instead of:

$fields['roles']

I used:

$fields['data']['roles'] and got better results.

Which version of bakery do I have to use the test module with?

I'm guessing the version you moved this issue from, 1.x. That said, I think this makes more sense to solve as part of #1232914: Bakery 3.x and pluggable account management.