Option to skip entity access check for entity ID and rendered entity

Thank You! Thank You! Thank You, Gapple!

It never ceases to amaze me how the Drupal Universe seems to deliver exactly what I need when I need it. Doesn't happen every time, but it certainly happened this time!! Your patch fixed my problem exactly!

All the Best,
Steve

Is there a reason why the patch only adds this option for the entityreference_entity_view display?
The defafult is entityreference_label, and that's the display a migrated userrefence field gets.

Extended the patch to:
- add this setting to all 3 display types (label,id, rendered entity)
- do not render a link with the label if access is not allowed (and thus the check was "skipped")
- do not render the links of the rendered entity if access is not allowed (and thus the check was "skipped")

I'm not sure about skipping the access check when rendering the id. It is information disclosure, but it seems quite harmless as it was explicitly set by a site admin.

Note that when rendering a user in a given view mode, the rdf module does add a link to the user page in an "about" attribute in the div surrounding the user profile! Thus disclosing the id.

Rerolled against head

Patch in #7 works for me. Sorry I forgot to come back and post that.

#7 isn't working against current dev any more. This is due to the commit ...402293f9a (drupal.org/node/2140237) which adds an entity_access check inside getLabel()

That commit also caused some issues with #2153463: Restricted access results with user entityreference and #2180379: Entity reference "Restricted access" label where there should be none

New patch attached.

+++ b/plugins/selection/EntityReference_SelectionHandler_Generic.class.php
@@ -303,9 +303,14 @@ class EntityReference_SelectionHandler_Generic implements EntityReference_Select
+    if ($skip_access) {
+      return entity_label($target_type, $entity);
+    }
+
+    return entity_access('view', $target_type, $entity) === FALSE ? t('- Restricted access -') : entity_label($target_type, $entity);
   }

I would find this more readable:
return skip_access || entity_access('view', $target_type, $entity) !== FALSE
? entity_label($target_type, $entity)
: t('- Restricted access -');

OTOH, this patch works, so I would be fine with this as well.

Duplicate of #1443344: Skip entity_access() check if SQL rewriting is disabled for the view, perhaps?

In fact:
- this patch resolves the concern mentioned in comment #19 of your mentioned issue
- this patch works for other cases as well, not only the Rendered Entity format.
- the naming of the other issue is misleading as it is not generic enough.

So let's close the the other issue as a duplicate of this one and let's focus on the patch here.

To give it a go, my concern in #10 is not enough to not set it to RTBC.

@Amitaibu, is it possible that this patch will be accepted?

@fietserwin,

1. Was resolved the next day.
2. Fair enough, I hadn't tested others yet.
3. The issue can be renamed by anyone.

That said, a quick look at this patch.

+++ b/entityreference.module
@@ -1164,6 +1175,10 @@ function entityreference_field_formatter_settings_summary($field, $instance, $vi
 
+  if (!empty($settings['skip_access'])) {
+    $summary[] = t('Skip access check for referenced entity');
+  }
+

Although it's understood (and currently the only option), it might be good for the summary to also indicate when the option isn't selected. e.g. "Don't skip access check...".

Based on #9 there are 2 minor changes.

Skip access check is now outside getLabel() to simplify things. Summary information has been updated as per my comment in #14.

Missed a couple of skip access checks. The previous patches didn't appear to work for Rendered Entity display format.

Good to go.

While still waiting for this to be commited, someone might be interested in Entity reference access

This works great. Can we get a commit?! :D

I can also confirm
* this patch implements an important feature
* it still applies
* it does what it announces

So RTBC.

This is RTBC since a long period of time and an important patch. What about a new dev version to try this and finally the new 7.x-1.2 release?

This patch works great for my needs but I have simple enhancement. In my case, I have a content type with an entity reference to users. I want to always display the user's label but only link to the user if they have 'view user profiles' permission. I configured the field display to link to the referenced entity. In entity_reference_field_formatter_view() I changed

        // If the link is to be displayed and the entity has a uri, display a link.
        // Note the assignment ($url = ) here is intended to be an assignment.
        if ($display['settings']['link'] && $item['access'] && ($uri = entity_uri($field['settings']['target_type'], $item['entity']))) {
          $result[$delta] = array('#markup' => l($label, $uri['path'], $uri['options']));
        }
        else {
          $result[$delta] = array('#markup' => check_plain($label));
        }

to

       // If the link is to be displayed and the entity has a uri, display a link.
        // Note the assignment ($url = ) here is intended to be an assignment.
        if (entity_access('view', $field['settings']['target_type'], $entity) && $display['settings']['link'] && $item['access'] && ($uri = entity_uri($field['settings']['target_type'], $item['entity']))) {
          $result[$delta] = array('#markup' => l($label, $uri['path'], $uri['options']));
        }
        else {
          $result[$delta] = array('#markup' => check_plain($label));
        }

So we only display the link if the user has access to view the entity.

Immediately found an error in the previous patch. I was passing the wrong $entity to the entity_access() check I added which causes all kind of issues if rendering a entityreference inside of a multifield.

Somehow uploaded an empty patch file. Here is the correct one.

@bkat: Thank you for your contributions...

...,but:
> This patch works great for my needs but I have simple enhancement.

Please open a separate issue for that.
The usual and good practice is to keep issues and patches atomic in the sense not to mix up different issues.

Otherwise we would get perfect monster patches after an infinite amount of time...

So to summarize: The RTBC patch is #16!

So tricking the bot by re-uploading #16 patch.

Duplicate of #2247937: add option to label formatter to show labels without considering user access?

I also consider this a duplicate of #2247937: add option to label formatter to show labels without considering user access. Closing. If people feel this issue covers more, they can reopen again.

The other issue only covers a subset of the use cases for this issue, so they are not duplicates, though the other one could have been closed a s duplicate of this.

However, as chances are small that this issue ever gets in if we reopen it, I will leave it as is.

As I want to be abel to update modules without too much of a hassle I did not try to reroll this patch. So how did I solve my use case without this patch:

Use case:
I want to render a custom defined view mode of an entity that is not otherwise accessible to most users. More specifically, the netity type is user and I want to render the full name )= civility) instead of a non descript username, and this on a site where only administrators have access to all user profiles (and logged in users to their own profile).

The idea was to use a custom view mode (that only shows a few fields of the whle entity) and give every visitor access to these user entities via that view mode.

What did not work:
- Drupal does not allow to give access to user_view() (or more generally entity_view) based on view mode. Access is determined earlier when view mode is not known
- Entity API module sets the access callback to one of its own functions in hook_entity_info_alter() and assures that it runs last in this alter hook. So it is not possible to override the entity access callback.

What did work:
It is possible to override the label callback and I did so to return some fields of the user profile instead of the username. Unfortunately this module does a check_plain() on the label, disallowing perfectly normal tags like span and strong in the label. So I could not render the view mode I had defined but had to mimic it myself by retrieving the field values myself
(note this could be an issue on itself for this module: use filter_xss_admin instead of check_plain).

The other issue only covers a subset of the use cases for this issue, so they are not duplicates, though the other one could have been closed a s duplicate of this.

However, as chances are small that this issue ever gets in if we reopen it, I will leave it as is.

As I want to be abel to update modules without too much of a hassle I did not try to reroll this patch. So how did I solve my use case without this patch:

Use case:
I want to render a custom defined view mode of an entity that is not otherwise accessible to most users. More specifically, the entity type is user and I want to render the full name (+ civility) instead of a non-descript username, and this on a site where only administrators have access to all user profiles and logged in users to their own profile.

The idea was to use a custom view mode (that only shows a few fields of the whole entity) and give every visitor access to these user entities via that view mode.

What did not work:
- Drupal does not allow to give access to user_view() (or more generally entity_view) based on view mode. Access is determined earlier when the view mode is not known (Therefore I resorted to this module to implement the access override).
- Entity API module sets the access callback to one of its own functions in hook_entity_info_alter() and assures that it runs last in this alter hook. So it is not possible to override the entity access callback.

What did work:
It is possible to override the label callback and I did so to return some fields of the user profile instead of the username.

Note: unfortunately this module does a check_plain() on the label, disallowing perfectly normal tags like span and strong in the label. So I could not render the view mode I had defined but had to mimic it myself by retrieving the field values myself. This could be an issue on itself for this module: use filter_xss_admin() instead of check_plain() when rendering the label).

As @fietserwin stated above. #2247937: add option to label formatter to show labels without considering user access covered only subset of features from this issue. So, this one was not supposed to be closed as duplicate.

However, the patches from this thread is no longer applicable as changes from other issue thread is already got committed.

We wanted the feature to bypass access for "Rendered entity" field format as well. So, I have created new patch to cover it as well as for "Entity id" field formatter like earlier patches. So, re-opening the the thread.

Thanks for the patch @junaidpv in #38 exactly what I needed to display a selection of rendered users without giving permissions "View user profile" to all my users.

There have been at least 3 issues dealing with this issue. Looks like another one, not quite as comprehensive, was committed. Therefore I suspect the maintainers have little interest in looking at this one.

It's a shame but it happens. We are no longer producing new D7 sites for the most part. For existing sites we are using a version of the module with the patch in this issue.

> Looks like another one, not quite as comprehensive, was committed.

What does this mean?

I'm going by fietserwin's comments in #36/#37, I haven't done extensive testing myself.

I think the other issue only works with the label, not the rendered entity. At least 2 people think this is a duplicate of this one even though it doesn't cover everything this one does.

So the plan should be to rebase the patch and the issue title to reflect the new situation, or not?

That would be a good way forward yes. I haven't reviewed or tested the patch in #38. My comments reflect my view of how this feature request has panned out. Apologies for the negativity.

We currently can't afford the time to work on D7 tasks we no longer require. Some history:

1. First issue: #1443344: Skip entity_access() check if SQL rewriting is disabled for the view
2. This issue: #1967180: Option to skip entity access check for entity ID and rendered entity
3. Newest issue: #2247937: add option to label formatter to show labels without considering user access

#45: Thanks for summarizing!

Pro tip: Update the issue summary (IS) then this will stay visible. ;-)

Good idea #46. I've updated the title and added a very brief new scope. It's not a complicated idea but if anyone's keen they can expand on the issue summary. Hopefully this will keep things going for now.

Straight reroll.