The way "index" enpoints currently work isn't performing efficiently when a somewhat complex access system is defined on node (using node_access table).

The EntityFieldQuery blindly extract id from DB whether the access is allowed or not, leaving the task to a later loop to check entity_access() on each entity.

Problem : it makes the paging goes wrong...

For the specific use case of node, adding the "node_access" tag to the EFQ solves the problem by filtering node earlier in the process.

As it's specific to node entity type, we should introduce a way for other module to alter the EFQ before it goes executed.

CommentFileSizeAuthor
#2 services_entity-support_node_access-2629006-2.patch761 bytesgarphy

Comments

garphy created an issue. See original summary.

garphy’s picture

garphy
Primary language French
Location Montreal, Canada
commented
Status: Active » Needs review
StatusFileSize
new services_entity-support_node_access-2629006-2.patch761 bytes

Here's a proposal patch to gather some feedback.

It allows another module to do :

/**
 * Implements hook_services_entity_index_query_alter().
 */
function services_entity_extensions_services_entity_index_query_alter(&$efq, $entity_type, $context) {
  if($entity_type == 'node') {
    $efq->addTag('node_access');
  }
}
kil’s picture

kil commented

I'm also in need of a predictable output for paging. Currently this is not working if you have unpublished content and/or permission restrictions for content. So I can confirm the report of garphy (and I would go so far to suggest that this is more of a bug than a feature, e.g. I get back from services_entity using ?parameters[type] - which is refering to a specific content type - "No entities found" because the first 20 items of the content type are not published: I need to increase ?pagesize to get back my expected results; paging is not possible with this behaviour).

Thank you garphy for the proposal patch. It worked at first for me, but it has a side effect if you are using ?parameters[x] where x is refering to a Term reference field. In this case EntityFieldQuery is creating a query that doesn't include the node table, instead it is based on an associative table. Adding the tag 'node_access' creates for the EntityFieldQuery a call to the function node_query_field_storage_details (correct) and node_query_node_access_alter (problems), the last one leading to a check on nid that is not working because the query is not connected to the node table. The consequence is a corrupt sql statement (in my case the x of ?parameters[x] is field_tags): "Unknown column 'field_data_field_tags0.nid' in where clause" (because there is no nid in this table but instead an entity_id and an entity_type). I'm not sure how to solve this problem (found some issues at other modules with this error message e.g. https://www.drupal.org/node/2245827), so before I try to dive deeper into it, maybe someone has already a solution for this?