Блокировка vs удаление пользователя в 1С-Битрикс

Блокировка и удаление пользователя — на первый взгляд похожие операции, но с разными последствиями для связанных данных: заказов, комментариев, истории действий. Разберём разницу и как сделать правильный выбор в зависимости от ситуации.

Блокировка через деактивацию

<?php

$user = new CUser;
$user->Update($userId, ['ACTIVE' => 'N']);

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

Программное удаление пользователя

<?php

CUser::Delete($userId);

Удаление физически убирает запись пользователя из таблицы — необратимая операция, после которой восстановить учётную запись без резервной копии базы данных невозможно. Прежде чем вызывать этот метод, стоит явно продумать судьбу всех связанных с этим пользователем данных.

Нужна помощь с Битрикс?

Что происходит со связанными заказами при удалении

Удаление пользователя не удаляет автоматически связанные с ним заказы — они остаются в базе, но поле, ссылающееся на пользователя, указывает на несуществующий ID. Код, рассчитывающий получить данные автора заказа через CUser::GetByID, должен корректно обрабатывать ситуацию отсутствия пользователя, иначе отображение истории заказов для администратора сломается при просмотре заказов удалённых клиентов.

Почему блокировка обычно безопаснее удаления

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

Требования законодательства о персональных данных

Для сценариев, где пользователь явно требует полного удаления своих персональных данных (право на удаление по 152-ФЗ и аналогичным требованиям), простой деактивации недостаточно — требуется реальное удаление или обезличивание персональных данных, при этом технически можно сохранить связанные заказы и статистику в обезличенном виде, заменив персональные поля пользователя на неидентифицирующие значения вместо удаления всей записи целиком.

<?php

$user = new CUser;
$user->Update($userId, [
    'NAME' => 'Удалён',
    'LAST_NAME' => '',
    'EMAIL' => 'deleted_' . $userId . '@example.invalid',
    'PERSONAL_PHONE' => '',
    'ACTIVE' => 'N',
]);

Массовая деактивация неактивных аккаунтов

<?php

function deactivateInactiveUsers(): string
{
    $result = \Bitrix\Main\UserTable::getList([
        'select' => ['ID'],
        'filter' => [
            'ACTIVE' => 'Y',
            '<LAST_LOGIN' => new \Bitrix\Main\Type\DateTime('-2 years'),
        ],
    ]);

    while ($row = $result->fetch()) {
        $user = new CUser;
        $user->Update($row['ID'], ['ACTIVE' => 'N']);
    }

    return 'deactivateInactiveUsers();';
}

Агент, деактивирующий аккаунты без входа за длительный период, — практика для проектов с политикой очистки неактивных учётных записей, снижающая риск компрометации давно забытых аккаунтов без физического удаления данных, которые могут понадобиться позже.

Частые ошибки

Удаление вызывается вместо блокировки без веской причины. Необратимая операция там, где хватило бы обратимой деактивации.
Код не обрабатывает отсутствие пользователя у старого заказа. Ошибка при просмотре истории заказов удалённых клиентов.
Полное удаление вместо обезличивания при запросе на удаление персональных данных. Теряется связанная история заказов, которая могла быть сохранена в обезличенном виде.

Итог

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

Теги: Безопасность Пользователи