0

EDIT: I have most probably found out the reason thy it works (or doesn't work actually) this way. The problem is that I don't have legitimate access to the user node that is being edited. I only 'hacked' the menu system so it let me through but don't really have the real access. Unfortunately I have no idea how to resolve this problem...

I have reworked the system that handles permission to user edit pages so that it allowed editing certain users even without the 'administer users' permission.

The system itself works well, the only problems are entity reference fields on the user. To be more specific, there are two entity reference fields attached to user bundle -> one that references another user 'supervisor' and another that references certain content type.

The problem with these two fields is that the autocomplete feature (I use autocomplete widgets) in the widgets not only doesn't work but even throws a 'access denied' error (in AJAX response).

It works well when current user has the 'administer users' permission but I can't give every user this permission.

BTW: To make it perfectly clear, not even the field that references a normal content type (node) works so the problem can't be in access to user entities as the answer below suggests.

I have tried to look into the entity reference code but have not found anything that would explain this strange behaviour (there's literally zero calling of user_access that might lead to this kind of behaviour).

  • If the referenced entity isn't accessible by the current user, it will throw an error. To make it referenceable you'll need to either 1. Change access permissions. 2. Change entity reference code logic. – David Thomas Nov 3 '13 at 22:29
  • @DavidThomas Your answer would explain why the field that references users doesn't work but what about the other one that references simple nodes that are accessible to everyone and doesn't work either? – Petrroll Nov 3 '13 at 22:43
0

You could try creating an entityreference display in views which, with the 'access' options defined in views, handle user access however you please.

Here is an example view display to get you started: https://gist.github.com/acao/7297342

Just configure the field settings to use this view instead of the default handler, and see if that gets you around your problem!

  • I can't do that because I have to use my own slightly altered entity reference selection handler (that does things you can't do in views). (btw: it doesn't work even if I use the default handler, I tried that). BTW2: Since there's no user_access code in the general entity reference handler I doubt it would help. – Petrroll Nov 4 '13 at 7:36
0

Ok, I've found where the problem was. There's an entity_access call in the entityreference module that caused the access denied error.

function entityreference_autocomplete_callback_get_matches($type, $field, $instance, $entity_type, $entity_id = '', $string = '') {
          $matches = array();

          $entity = NULL;
          if ($entity_id !== 'NULL') {
            $entity = entity_load_single($entity_type, $entity_id);
            if (!$entity || !entity_access('view', $entity_type, $entity)) {
              return MENU_ACCESS_DENIED;
            }
          }
        ...
}

The entity access then called entity_metadata_user_access which implements traditional way of handling user access.

To solve this problem I just altered the entity_info, more specifically the access_callback function of user entity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.