Форум

На сегодняшний день $USER === null в агентах на кроне - это документированная особенность, и пишут следующее:
[QUOTE]
Переменная USER в агентах отсутствует. Точнее она может быть создана на сервере хостинга, но нет никакой гарантии, что это будет объект класса CUser.
При необходимости рекомендуется создавать в агенте объект $USER, что-то с ним сделать и уничтожить.

Источник: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=3436
[/QUOTE]

Добавлю сюда актуальный способ, потому что Яндекс выдает эту тему первой в результатах.

На всех устройствах:
[CODE]\Bitrix\Main\UserAuthActionTable::addLogoutAction($userId);[/CODE]

На всех устройствах, кроме текущего:
[CODE]global $USER;
$USER->SetParam("AUTH_ACTION_SKIP_LOGOUT", true);
\Bitrix\Main\UserAuthActionTable::addLogoutAction($USER->GetID());[/CODE]

Наткнулся на этот баг в orm-сущности ядра. Фиксится так:

[CODE]
use Bitrix\Sale\Internals\ServiceRestrictionTable;
use Bitrix\Main\ORM\Fields\ArrayField;

$restrictionsEntity = ServiceRestrictionTable::getEntity();

// Поле с правильной десериализацией значения.
$restrictionsEntity->addField(
   (new ArrayField('PARAMS'))->configureSerializationPhp(),
   'PARAMS_AS_ARRAY'
);

$restriction = ServiceRestrictionTable::getList([
   'select' => [
       'PARAMS_AS_ARRAY'
   ]
])->fetchObject();

$params = $restriction->getParamsAsArray();
[/CODE]

[QUOTE]Антон Штинов написал:
Прошло более трех лет... Проблема так и не решена.
Кеш сео-данных для элемента не сбрасывается при изменении элемента.
Так и не смог предположить, чем обусловлена такая реализация.[/QUOTE]

При каждом изменении кэш для seo тоже сбрасывать неразумно. Могут меняться поля, которые к seo никак не относятся и кэш от них не зависит.

Поэтому пользуйтесь
[CODE]use Bitrix\Iblock\InheritedProperty;
......
$ipropValues = new InheritedProperty\ElementValues($arFields['IBLOCK_ID'], $arFields['ID']);
$ipropValues->clearValues(); [/CODE]в событии после изменения элемента инфоблока в общем случае.

В частном можно проверку добавить, что было изменение полей, от которых зависит Ваш кэш.

Проверил как работает код из \Bitrix\Catalog\CatalogViewedProductTable::getProductSkuMap.
Пробовал разные кейсы - по результатам запросы совпадают, для множественной привязки мое решение работает.

Мои вводные данные: нет документооборота, количество привязок 60 000, количество элементов 50 000, количество разделов 1000. На таком наборе не получил выигрыша от ... INNER JOIN (SELECT ... INNER JOIN (SELECT ... ) ...) ...

В абсолютных значениях разница мизерная так как оба варианта работают довольно быстро. В процентных мое на 30% быстрее и повторные запросы лучше база оптимизирует, поэтому оставил его.

Решение. Думал, что если сразу присоединять таблицу с нужными разделами, а потом к ним присоединять таблицы связи и элементов, то будет быстрее. На практике разница в скорости выборки почти не видна.
[CODE]
\Bitrix\Main\Loader::includeModule('iblock');
\Bitrix\Main\Application::getConnection()->startTracker(true);
$elements = \Bitrix\Iblock\ElementTable::getList([
           'filter' => [
'ROOT.ID' => 947, // Раздел, в котором ищем включая подразделы.
'==LINK.ADDITIONAL_PROPERTY_ID' => NULL, // Основная привязка элементов к группам.
'ACTIVE' => 'Y' // Активные элементы.
           ],
           'sel ect' => [
'ID',
           ],
   'group' => [
'ID'
   ],
           'runtime' => [
               'LINK' => [
                   'data_type' => \Bitrix\Iblock\SectionElementTable::class,
                   'reference' => [
                       '=this.ID' => 'ref.IBLOCK_ELEMENT_ID',
                   ],
   'join_type' => 'inner',
               ],
               'PARENT' => [
                   'data_type' => \Bitrix\Iblock\SectionTable::class,
                   'reference' => [
                       '=this.LINK.IBLOCK_SECTION_ID' => 'ref.ID',
                   ],
   'join_type' => 'inner',
               ],
               'ROOT' => [
                   'data_type' => \Bitrix\Iblock\SectionTable::class,
                   'reference' => [
                       '=this.PARENT.IBLOCK_ID' => 'ref.IBLOCK_ID',
                       '<=ref.LEFT_MARGIN' => 'this.PARENT.LEFT_MARGIN',
                       '>=ref.RIGHT_MARGIN' => 'this.PARENT.RIGHT_MARGIN',
                   ],
                   'join_type' => 'inner',
               ],
           ]
       ]);

\Bitrix\Main\Application::getConnection()->stopTracker();

var_dump($elements->fetch());

print_r(\Bitrix\Main\Application::getConnection()->getTracker());
[/CODE]

Получаем запрос
[CODE]
SELECT
`iblock_element`.`ID` AS `ID`
FR OM `b_iblock_element` `iblock_element`
INNER JOIN `b_iblock_section_element` `iblock_element_link` ON `iblock_element`.`ID` = `iblock_element_link`.`IBLOCK_ELEMENT_ID`
INNER JOIN `b_iblock_section` `iblock_element_parent` ON `iblock_element_link`.`IBLOCK_SECTION_ID` = `iblock_element_parent`.`ID`
INNER JOIN `b_iblock_section` `iblock_element_root` ON `iblock_element_parent`.`IBLOCK_ID` = `iblock_element_root`.`IBLOCK_ID`
AND `iblock_element_root`.`LEFT_MARGIN` <= `iblock_element_parent`.`LEFT_MARGIN`
AND `iblock_element_root`.`RIGHT_MARGIN` >= `iblock_element_parent`.`RIGHT_MARGIN`
WHERE `iblock_element_root`.`ID` = 947
AND `iblock_element_link`.`ADDITIONAL_PROPERTY_ID` IS NULL
AND UPPER(`iblock_element`.`ACTIVE`) like upper('Y')
GROUP BY `iblock_element`.`ID`
[/CODE]

[QUOTE]Алексей Шафранский написал:
Исправлена ошибка обновления образов для VirtualBox (процесс зависал из-за ошибки в MySQL).
Ссылки для скачивания VMBitrix:
http://repos.1c-bitrix.ru/vm/VMBitrix7.4-3-CentOS7.7-VirtualBox.zip
[/QUOTE]
Опубликуйте пожалуйста на странице https://www.1c-bitrix.ru/download/cms.php ссылку на образ 7.4.3 для VirtualBox. Образ для VirtualBox, который сейчас с этой страницы можно скачать по сути мертвый, т.к. mysql в этом образе не работает нормально и обновить его до 7.4.3 тоже нельзя опять же из-за mysql.