copy 'administer media browser' permissions to 'access media browser' permissions.

see patch

Edit 7226 so as to not break other patches after the introduction of this problem (there's already a 7227 in another patch) , just fix this 7226 once for the next release as there is a workaround noted in the description of this issue.

BEFORE

/**
 * Accommodate the introduction of a new permission which restricts access to
 * the media browser by granting it to existing users who were able to access
 * it.
 */
function media_update_7226() {
  $roles = user_roles(FALSE, 'create files');

  foreach ($roles as $rid => $role) {
    user_role_grant_permissions($rid, array('access media browser'));
  }
}

NEW CODE (had to test it as a higher number 722x for testing increase x as number desired/required for drush updatedb to pick it up)

/**
 * Redo update_7226 as previous patch inadvertently copied
 * from 'create files' instead of 'administer media browser'
 * Accommodate the introduction of a new permission which restricts access to
 * the media browser by granting it to existing users who were able to access
 * it.
 */

function media_update_7226() {
  $roles = user_roles(TRUE, 'administer media browser'); //pass TRUE to exclude the 'anonymous' role https://api.drupal.org/api/drupal/modules!user!user.module/function/user_roles/7

  foreach ($roles as $rid => $role) {
    user_role_grant_permissions($rid, array('access media browser'));
  }
}

Ok, while the role 'create files' for the 'file_entity' module makes sense , the value "false" passed as a parameter to "user_roles" might be what is causing our problem.

drupal api page

$membersonly: Set this to TRUE to exclude the 'anonymous' role.

So, we should be passing "true" as a parameter instead of "false" as we don't want anonymous users to have access to the media browser (at least not by default).

Also, it does make sense that users that have 'administer media browser' permissions should be able to 'access media browser' but in our case (wetkit distro v1.5) we get 'access denied' when clicking the media browser button until the permissions are manually assigned through the admin interface.

How about if both were copied? 'create files' and 'administer media browser' just to make sure (and it would help us not have to make our own update hook outside of the media module)?

Thanks for the quick response.
ok, I did some more testing, in our distro the hook never gets fired, most likely because we're using various versions of patched media modules and it's likely that the update_7226 was already triggered by a different version that didn't actually update the permissions correctly. I tested by cleaning my db, reloading to a baseline and then changing the update_7226 to update_7228 , I'll have to check the schema table to verify, but it looks like our schema was at update_7227 , so the update_7226 must have been fired previously with a different patch and therefore never actually copied any permissions as it did something else with a previous patch code.

I'll close this again, it's on our distro side obviously. Although using the "true" parameter wouldn't hurt.

Thanks