Текущий пользователь в Bitrix D7: CurrentUser вместо устаревших вызовов $USER

Зачем смотреть на CurrentUser

В свежих версиях «главного» модуля разработчики подталкивают к работе через \Bitrix\Main\Engine\CurrentUser: часть методов глобального $USER для проверки авторизации помечена устаревшими и в перспективе может привести к предупреждениям или ошибкам. Для нового кода удобнее опираться на единый фасад, который хорошо вписывается в D7-сервисы и компоненты с зависимостями.

Получить объект и понять, гость это или нет

Статический фабричный метод возвращает обёртку над контекстом запроса:

use Bitrix\Main\Engine\CurrentUser;

$ctx = CurrentUser::get();
$userKey = $ctx->getId(); // int или null у гостя

if ($userKey) {
    // пользователь авторизован
}

Проверка «есть ли ID» остаётся простым и быстрым критерием для шаблонов и обработчиков. Там, где важна явная семантика, можно дополнительно сочетать это с правами и группами ниже.

Роли, группы и админка

Для типовых ветвлений в административной части и проверки принадлежности к группам:

$isSiteAdmin = $ctx->isAdmin();
$groupIds = $ctx->getUserGroups(); // массив идентификаторов групп

Разделение «админ сайта» и произвольных групп полезно помнить при кастомных модулях: не смешивайте проверку одной встроенной ролью с бизнес-правилами по группам без явного ТЗ.

Имя для интерфейса и контакты

Объект даёт готовые строки для вывода и разбор ФИО без ручной склейки из глобальных массивов:

• getFormattedName() — имя по правилам настроек сайта.
• getFullName(), getName(), getLastName(), getSecondName() — поле за полем.
• getLogin() и getEmail() — учётная запись и почта.

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

Операции и дополнительные поля из базы

Для интеграции с моделью прав по операциям используйте canDoOperation($operationCode) — код операции задаётся конфигурацией модулей. Если в шаблоне нужны произвольные колонки (например, телефон авторизации), одной строкой можно запросить строку через ORM:

use Bitrix\Main\UserTable;

if ($ctx->getId() && $ctx->canDoOperation($operationCode)) {
    // логика при наличии права на операцию $operationCode
}

if ($ctx->getId()) {
    $row = UserTable::getRow([
        'filter' => ['=ID' => (int) $ctx->getId()],
        'select' => ['ID', 'PHONE' => 'PHONE_AUTH.PHONE_NUMBER'],
    ]);
}

Список полей в select подставьте под реальную схему связей в проекте; для редких полей проверяйте, что модуль подключён и индексы позволяют не бить по полной таблице на каждом хите.

Практические замечания

• В консольных скриптах и агентах контекст «текущего» пользователя может отличаться от веба — инициализируйте окружение так же, как для остального ядра.
• Не дублируйте проверки там, где достаточно одного уровня: сначала авторизация, затем права или бизнес-правила.
• При миграции старых сниппетов на CurrentUser перепроверьте места, где раньше вызывали устаревшие методы у $USER только ради булева флага.

Итог

CurrentUser::get() закрывает типовой сценарий: кто пришёл на сайт, как его звать, к каким группам относится, может ли выполнить операцию и как при необходимости подтянуть дополнительные поля через UserTable. Это ровная замена привычным вызовам у глобального пользователя в новом коде.