Как перевести экстранет-пользователя в интранет в коробке

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

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

На практике обычно важны три вещи:

• пользователь активен;
• у пользователя заполнено подразделение в поле UF_DEPARTMENT;
• пользователь состоит в группе сотрудников основного портала, например Моя компания: Сотрудники.

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

Поэтому перевод лучше воспринимать не как одно поле «экстранет/интранет», а как набор связей: подразделение, группы, права и старые экстранет-группы.

Обычно порядок такой:

• открыть профиль экстранет-пользователя;
• найти действие перевода в интранет;
• выбрать подразделение компании;
• сохранить изменения;
• проверить, что пользователь появился среди сотрудников.

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

Сначала можно вывести текущие данные пользователя:

use Bitrix\Main\Loader;

const USER_ID = 123;

Loader::includeModule('intranet');

$user_result = CUser::GetByID(USER_ID);
$user = $user_result->Fetch();

echo '<pre>';
print_r([
    'ID' => $user['ID'] ?? null,
    'LOGIN' => $user['LOGIN'] ?? null,
    'ACTIVE' => $user['ACTIVE'] ?? null,
    'UF_DEPARTMENT' => $user['UF_DEPARTMENT'] ?? null,
    'GROUPS' => CUser::GetUserGroup(USER_ID),
]);
echo '</pre>';

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

$group_result = CGroup::GetList(
    'id',
    'asc',
    [
        'STRING_ID' => 'EMPLOYEES',
    ]
);

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

Если по символьному коду группа не находится, можно искать по названию:

$group_result = CGroup::GetList(
    'id',
    'asc',
    [
        'NAME' => 'Сотрудники',
    ]
);

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

После этого можно добавить пользователя в подразделение и в группу сотрудников:

const USER_ID = 123;
const DEPARTMENT_ID = 15;
const EMPLOYEES_GROUP_ID = 11;

$current_groups = CUser::GetUserGroup(USER_ID);

$new_groups = array_unique(array_merge(
    $current_groups,
    [EMPLOYEES_GROUP_ID]
));

$user = new CUser();

$update_result = $user->Update(USER_ID, [
    'GROUP_ID' => $new_groups,
    'UF_DEPARTMENT' => [DEPARTMENT_ID],
]);

if (!$update_result) {
    echo $user->LAST_ERROR;

    return;
}

echo 'Пользователь переведён в подразделение и добавлен в группу сотрудников';

Метод CUser::Update изменяет параметры пользователя по ID и возвращает ошибку через LAST_ERROR, если изменение не удалось.

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

BX24.callMethod(
    'user.update',
    {
        ID: 123,
        UF_DEPARTMENT: [15],
    },
    function (result) {
        if (result.error()) {
            console.error(result.error());

            return;
        }

        console.log(result.data());
    }
);

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

const USER_ID = 123;
const EMPLOYEES_GROUP_ID = 11;
const EXTRANET_GROUP_IDS = [16, 17];

$current_groups = CUser::GetUserGroup(USER_ID);

$new_groups = array_diff($current_groups, EXTRANET_GROUP_IDS);
$new_groups[] = EMPLOYEES_GROUP_ID;

$new_groups = array_values(array_unique($new_groups));

$user = new CUser();

$update_result = $user->Update(USER_ID, [
    'GROUP_ID' => $new_groups,
]);

if (!$update_result) {
    echo $user->LAST_ERROR;
}

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

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