I ran into problems with using RulesAction "Fetch entity by property" for file entities: my component didn't appear among available VBO operations. The reason was failing access check which returned FALSE for $op = 'view' and $entity_type = 'file'.

The function entity_metadata_file_access($op, $file = NULL, $account = NULL, $entity_type) responsible for this does so because no $file object is given.

Steps to reproduce:

1. Create an Action Set component with a parameter of type Entity = say "Node", then add action "Fetch entity by property", set Entity Type = "File" and property say filename = anything.
2. Now enable this component in VBO field of a view which lists Nodes.
3. Visit view page - the operation added doesn't appear in the operations list.

#9 entity-file_entity_access-1831578-9.patch741 bytesParisLiakos
PASSED: [[SimpleTest]]: [MySQL] 374 pass(es). View
#1 entity-1831578-1.patch1.07 KBOnkelTem
PASSED: [[SimpleTest]]: [MySQL] 374 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


OnkelTem’s picture

Status: Active » Needs review
1.07 KB
PASSED: [[SimpleTest]]: [MySQL] 374 pass(es). View

In this patch file access check is delivered to File Entity's file_entity_access() callback.

OnkelTem’s picture

Issue summary: View changes


OnkelTem’s picture


fago’s picture

Status: Needs review » Postponed (maintainer needs more info)

What does file entity's callback do? Is this function compliant as access callback? How does it handle the case when no entity is given?

keesje’s picture

This patch is working for me.
I doubt that this is the most sane "solution" though.
entity_metadata_file_access validates only "view" as TRUE for $op. VBO can ask permissions for ops:

  $access_ops = array(
    VBO_ACCESS_OP_VIEW => 'view',
    VBO_ACCESS_OP_UPDATE => 'update',
    VBO_ACCESS_OP_CREATE => 'create',
    VBO_ACCESS_OP_DELETE => 'delete',

see _views_bulk_operations_entity_access().

So, if access is checked for any other $op than "view" for entity type "file", validation will allways return "false" since "entity_metadata_file_access" is triggered. And we know entity_metadata_file_access only accepts "view" as a valid $op.

Bottomline is that an entity type can only have 1 "access callback". And entity.module and file_entity.module both try set it. So, it comes down to the order of module execution. Which can be altered by changing the module weight in the system table.
Setting weight on file_entity.module to 1 solved this problem for me. In my case and opinion this is a cleaner solution than the patch in #1.

rooby’s picture

Status: Postponed (maintainer needs more info) » Needs review


I'm not really sure what makes a compliant access callback but here is some information on what file_entity_access does (in order):

  • If there is no entity it always returns FALSE for the ops 'view', 'download', 'update', 'delete', 'create'.
  • For create it checks against its file creation permissions.
  • For other ops it invokes hook_file_entity_access() after which any DENYs trump any ALLOWs. - These rights are also statically stored so the hook is not invoked if a DENY or ALLOW was previously returned. - The module also has its own implementation of hook_file_entity_access(), which does the following:
    • For ops 'create', 'download', 'update', 'delete', permissions are checked.
    • For the view op, hook_file_download() is invoked.
  • For view (if no DENY or ALLOW was returned from the invocation of the hook) it uses its file viewing permissions.
rooby’s picture

Oops, I though I already posted this but these are my findings on the current solutions:

The patch in #1 fixed my problem of user 1 getting insufficient permissions errors when updating/deleting file entities with views bulk operations.

I also agree that the solution in #1 seems hacky though.

The solution in #4 (setting the weight of the file_entity module to 1) did not fix it.

Also, changing the weight of a module that other modules build on top of (like file_entity) has the potential to cause other issues with other contrib modules.

rooby’s picture

Marked #1897272: Insufficient permissions when using user 1 as a duplicate of this issue.

gmclelland’s picture

ParisLiakos’s picture

741 bytes
PASSED: [[SimpleTest]]: [MySQL] 374 pass(es). View

I think this is a better way.no need to go through entity_metadata_file_access if file_entity_access exists

gmclelland’s picture

populist’s picture

Status: Needs review » Reviewed & tested by the community

I also ran into this problem and see that it is quite common. I checked out the patches here and #9 worked for me.

Marking #9 RTBC because it looks to be the most elegant of the approaches and this issue seems to be a blocker for a few folks. #1 is quite similar in approach, but directly calling functions in file_entity.module seems not as great as simply understanding that if file_entity.module is available then it has its own access function which, as per #5, seems to do what it is suppose to do.

fago’s picture

Status: Reviewed & tested by the community » Fixed

#9 is reasonable. Thanks, committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

firfin’s picture

wodenx’s picture

Category: task » bug
Status: Closed (fixed) » Active

Reopening because the approach above breaks file entity access when Media 1.3 is installed (and this is still the recommended release).
The 'file_entity_access' callback was introduced in File Entiyt 2.x - and isn't present in the version bundled with Media 1.3.

See #2094833: Allow modules to insert alternative access callbacks for a proposed solution.

wodenx’s picture

Issue summary: View changes

Updated issue summary.