The user edit link provided by Views doesn't take into consideration our new permissions.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

minorOffense’s picture

Status: Active » Needs review
FileSize
1.82 KB

The latest dev has this code started but doesn't quite work yet. There's an access() method called in the parent classes for the views handlers which checks if the current user has access to view user profiles

http://api.drupal.org/api/views/modules%21user%21views_handler_field_use...

In our case, we want to check if a given user has access to a specific account given a specific role. Unfortunately, at the time access() is run, the query hasn't been run yet and so we can't run an access check against that user.

Unless we require that any user who requires access to edit/cancel users using this module to also have the permission "access user profiles", we'll need to override the access function to return TRUE regardless.

If not, then we should add docs stating that you need to ensure the user has "access user profiles" permission set on their role to use the Views integration.

I've included a patch which sets the access to TRUE if that's the method you'd like to use. Otherwise, I can supply a patch with a README.txt describing what to do (and perhaps some extra text in Views to explain what to do).

GeduR’s picture

Patch #1 works but there is other related issue.

If the current users needs to create other users the "administer users" permission needs to be assigned because in the core register form there is a drupal_goto protection...

user.module 3705
function user_register_form($form, &$form_state) {
  global $user;

  $admin = user_access('administer users');
  ...
  // If we aren't admin but already logged on, go to the user page instead.
  if (!$admin && $user->uid) {
    drupal_goto('user/' . $user->uid);
  }

So all this kind of users needs this permission('administer users'), because of that in the handler we can't ask for this permission because it will be always true. The links is rendered as normal but the user has no access.

Views handler: wrong

if ($data && (user_edit_access($account) || _administerusersbyrole_can_edit_user($account))) {
...
}

Menu alter: the expected behavior without ('administer users')

$items['user/%user/edit']['access callback'] = '_administerusersbyrole_can_edit_user';

Attaching the patch that complements the first one (#1), I don't include the first one in this patch because it's a different (related) issue and maybe some people thinks that "access user profiles" is necessary to edit an user (me not).

AdamPS’s picture

Component: Code » Documentation
Issue summary: View changes
Status: Needs review » Needs work

In #1

If not, then we should add docs stating that you need to ensure the user has "access user profiles" permission set on their role to use the Views integration.

That seems like the answer to me. If you have permission to alter user profiles it seems entirely reasonable that you ought to also set permission to view them. I'd almost say it's obvious, but seeing as you don't feel the same way I'll see if we can make this clearer in the docs.

The patch in #1 as supplied looks like it ends up slightly altering how views of users work for all users, which I feel is undesirable.

AdamPS’s picture

Version: 7.x-1.x-dev » 7.x-2.0-beta1
Status: Needs work » Closed (fixed)

Now covered in README.txt file