Запуск запроса EntityFieldQuery для ограниченного содержимого (с помощью cron)

Question

Запуск запроса EntityFieldQuery для ограниченного содержимого (с помощью cron)

У меня небольшая проблема с выполнением следующего запроса:

$qry = new EntityFieldQuery();
$qry->entityCondition('entity_type', 'node')
        ->propertyCondition('status', 1)
        ->propertyCondition('changed', $since, '>')
        ->fieldCondition('group_audience', 'gid', (array) $groups, 'IN' );

Когда я запускаю это вручную от имени пользователя № 1, все в порядке. Когда я запускаю это через cron (у которого нет пользователя), управление доступом к органической группе, похоже, запрещает возвращать какие-либо результаты (на основе отсутствия разрешений для текущего пользователя, я полагаю). Эта проблема связана с последним условием поля, при удалении все работает должным образом.

2

database 7 organic-groups

Author: kalpaitch, 2013-03-18

Source

1 answers

score 3 · Accepted Answer

Cron запускается как аномальный пользователь. Идея заключается в том, что он должен вызывать только API, которые не требуют пользователей. Однако EntityFieldQuery позволяет либо обойти проверки доступа к узлу, либо указать пользователя, от имени которого будет выполняться запрос.

Вариант 1: Задайте пользователю для выполнения запроса следующее:

$query = new EntityFieldQuery;
$result = $query
  ->fieldCondtition(...)
  ->addMetaData('account', user_load(1))
  ->execute();

Вариант 2: Обойти доступ к узлу, установив тег DANGEROUS_ACCESS_CHECK_OPT_OUT (я полагаю, начиная с Drupal 7.15)

$query = new EntityFieldQuery();
$result = $query
  ->fieldCondition(...)
  ->addTag('DANGEROUS_ACCESS_CHECK_OPT_OUT')
  ->execute();

Вариант 3: Вы можете запустить свой cron-код от имени другого пользователя , установив глобальный $user переменная. Например:

function mymodule_cron() {
  global $user;
  $original_user = $user;
  $old_state = drupal_save_session();
  drupal_save_session(FALSE);
  $user = user_load(1);
  _mymodule_do_some_stuff();
  $user = $original_user;
  drupal_save_session($old_state);
}

Вариант 1 - это самый чистый способ выполнить то, что было запрошено - он основан на существующей функциональности для выполнения запроса от имени другого пользователя. Вы можете использовать пользователя 1 или создать пользовательского пользователя, у которого есть именно те разрешения, которые требуются для вашей операции.

Вариант 2 функционально эквивалентен использованию варианта 1 с пользователем 1. Он менее гибкий, чем вариант 1, поэтому на самом деле нет возможности его использовать (но включен здесь для полноты).

Варианты 1 и 2 ограничены запросом поля сущности, который задал ОП. Чтобы выполнять другие операции от имени другого пользователя, вам необходимо полностью выдать себя за этого пользователя, что и делает вариант 3.