Как понять, пользователь уволен или просто неактивен

Проблема

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

На этом месте часто появляется формулировка «пользователь неактивен». Но для разработки она слишком размытая. Один пользователь может быть уволен, другой — просто не заходил на портал, третий — приглашён, но ещё не зарегистрировался, четвёртый — активный экстранет-пользователь.

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

Уволен и неактивен — не одно и то же

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

В списке сотрудников такие пользователи попадают в отдельный фильтр «Уволены». Там же есть и другие готовые фильтры: действующие сотрудники, приглашённые пользователи, администраторы, экстранет и ожидающие подтверждения.

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

«Неактивен» в бытовом смысле может означать совсем другое: пользователь давно не входил, не установил приложение, не подтвердил приглашение или временно не участвует в рабочих группах. Это не то же самое, что увольнение.

Что смотреть в REST

В REST чаще всего используют метод user.get. У него есть фильтр ACTIVE: при значении true из результата исключаются уволенные пользователи.

Если нужно получить только действующего пользователя по ID, можно добавить ACTIVE: true:

BX24.callMethod(
    'user.get',
    {
        FILTER: {
            ID: 123,
            ACTIVE: true,
        },
    },
    function (result) {
        if (result.error()) {
            console.error(result.error());

            return;
        }

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

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

Для административной проверки лучше запросить пользователя по ID без фильтра ACTIVE, а уже потом разобрать полученные поля:

BX24.callMethod(
    'user.get',
    {
        FILTER: {
            ID: 123,
        },
        ADMIN_MODE: true,
    },
    function (result) {
        if (result.error()) {
            console.error(result.error());

            return;
        }

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

Отдельно полезно вывести статус, отделы и тип пользователя:

BX24.callMethod(
    'user.get',
    {
        FILTER: {
            ID: 123,
        },
        ADMIN_MODE: true,
    },
    function (result) {
        if (result.error()) {
            console.error(result.error());

            return;
        }

        const users = result.data();
        const user = users[0];

        console.log({
            id: user.ID,
            active: user.ACTIVE,
            departments: user.UF_DEPARTMENT,
            user_type: user.USER_TYPE,
        });
    }
);

В BI-датасетах Bitrix24 поле ACTIVE описывается прямо: Y — работает, N — уволен. В REST-ответах конкретный формат значения может зависеть от метода и обёртки, поэтому в коде лучше быть готовым к булевому и строковому варианту.

Структура и группы

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

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

BX24.callMethod(
    'user.get',
    {
        FILTER: {
            UF_DEPARTMENT: 15,
            ACTIVE: true,
            USER_TYPE: 'employee',
        },
    },
    function (result) {
        if (result.error()) {
            console.error(result.error());

            return;
        }

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

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

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

Как использовать в проверках

В коде лучше явно разделять несколько состояний: работает, уволен, не сотрудник, без отдела или неизвестный статус.

Пример нормализации статуса после получения пользователя:

function normalizeUserStatus(array $user): string
{
    $active_value = $user['ACTIVE'] ?? null;
    $departments = $user['UF_DEPARTMENT'] ?? [];
    $user_type = (string)($user['USER_TYPE'] ?? '');

    if ($active_value === false || $active_value === 'N') {
        return 'fired';
    }

    if ($user_type !== '' && $user_type !== 'employee') {
        return 'not_employee';
    }

    if (!is_array($departments) || count($departments) === 0) {
        return 'without_department';
    }

    return 'employee';
}

Такой подход удобнее, чем одна проверка вида «пользователь активен». Для назначения ответственного обычно нужен именно статус employee. Для аудита старых связей наоборот интересны fired и without_department.

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