Почему пользователя нельзя удалить: «является владельцем блога»

Текст ошибки может выглядеть так:

Пользователь является владельцем блога и не может быть удален

Смысл ошибки простой: в системе есть блог, у которого этот пользователь указан владельцем. Пока объект ссылается на пользователя как на владельца, удаление блокируется.

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

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

Даже если сейчас блогами никто явно не пользуется, записи в модуле могут остаться. Поэтому перед удалением старого пользователя нужно смотреть не только CRM и задачи, но и такие технические связи.

Если задача кадровая, а не техническая, чаще правильнее не удалять пользователя полностью, а уволить его. Так сохраняется история действий, задач, комментариев и CRM-активности.

В административной части сначала стоит посмотреть раздел с блогами и найти блог, где владельцем указан нужный пользователь. Если через интерфейс найти неудобно, можно использовать API модуля блогов.

Пример для командной PHP-строки или временного административного скрипта:

use Bitrix\Main\Loader;

const OLD_USER_ID = 123;

Loader::includeModule('blog');

$blog_result = CBlog::GetList(
    ['ID' => 'ASC'],
    ['OWNER_ID' => OLD_USER_ID],
    false,
    false,
    ['ID', 'NAME', 'URL', 'OWNER_ID', 'GROUP_ID']
);

while ($blog = $blog_result->Fetch()) {
    echo '<pre>';
    print_r($blog);
    echo '</pre>';
}

Здесь OLD_USER_ID — ID пользователя, которого не получается удалить. Скрипт выводит блоги, где этот пользователь указан владельцем.

Перед любыми изменениями лучше сначала просто вывести найденные данные и убедиться, что это действительно нужные блоги. Особенно если портал старый и в модуле блогов могут быть рабочие записи.

Безопаснее обычно заменить владельца. Например, передать блог администратору или сотруднику, который будет отвечать за оставшиеся записи.

use Bitrix\Main\Loader;

const OLD_USER_ID = 123;
const NEW_OWNER_ID = 456;

Loader::includeModule('blog');

$blog_result = CBlog::GetList(
    ['ID' => 'ASC'],
    ['OWNER_ID' => OLD_USER_ID],
    false,
    false,
    ['ID', 'NAME', 'URL', 'OWNER_ID']
);

while ($blog = $blog_result->Fetch()) {
    $blog_id = (int)$blog['ID'];

    if ($blog_id <= 0) {
        continue;
    }

    $update_result = CBlog::Update($blog_id, [
        'OWNER_ID' => NEW_OWNER_ID,
    ]);

    echo sprintf(
        'Блог %s: %s<br>',
        $blog_id,
        $update_result ? 'владелец изменён' : 'ошибка изменения владельца'
    );
}

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

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

use Bitrix\Main\Loader;

const BLOG_ID = 123;

Loader::includeModule('blog');

$delete_result = CBlog::Delete(BLOG_ID);

echo $delete_result ? 'Блог удалён' : 'Блог не удалён';

Этот вариант лучше использовать осторожно. Если цель — убрать сотрудника из активной структуры компании, а не очистить данные, увольнение или деактивация почти всегда безопаснее физического удаления.

Чаще всего стоит проверить задачи, рабочие группы, проекты, CRM-сущности, комментарии, посты, права и другие места, где пользователь может быть владельцем, ответственным, участником, постановщиком или наблюдателем.

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

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