Группы пользователей - назначение, срок действия, автоматизация
Разбираемся с группами: как из них складываются права, почему список групп легко затереть и как выдавать доступ на срок и автоматически.
Что нужно знать заранее
Права пользователя складываются из всех его групп сразу. Побеждает самое широкое право: запрет в одной группе не отменяет разрешения, полученного из другой.
Запись групп заменяет весь прежний список членства этого пользователя. Это самая дорогая ловушка темы: выдавая одну группу неаккуратно, легко снять с человека все остальные.
У членства в группе есть собственные даты начала и окончания действия. Просроченное членство платформа перестаёт учитывать сама, и вручную чистить такие записи не нужно.
Шаги
- Посмотреть текущие группы пользователя вместе со сроками до правки его доступа.
- Добавлять новую группу к текущему списку членства, а не записывать её одну.
- Для временного доступа задавать дату окончания членства сразу при выдаче группы.
- Автоматическое назначение вешать на событие, а не на скрипт по расписанию.
- Проверять результат выдачи под учётной записью самого пользователя, а не администратора.
Решение
Смотрим группы пользователя и сроки:
print_r(\CUser::GetUserGroup($userId)); // только номера групп$rs = \Bitrix\Main\UserGroupTable::getList(['filter' => ['=USER_ID' => $userId], 'select' => ['GROUP_ID', 'DATE_ACTIVE_FROM', 'DATE_ACTIVE_TO']]);print_r($rs->fetchAll()); // здесь видно и сроки членстваprintf("группа 1 - администраторы, группа 2 - все пользователи\n");Номера групп без сроков отвечают не на все вопросы. Жалоба «доступ пропал сам» почти всегда объясняется датой окончания членства, которую поставили и забыли.
Добавляем группу, не теряя прежние:
$current = \CUser::GetUserGroup($userId);\CUser::SetUserGroup($userId, array_unique(array_merge($current, [$dealerGroupId])));// без слияния со списком человек потеряет все остальные группы разомСлияние с текущим списком - обязательная часть любой выдачи. Скрипт, который пишет одну группу, снимает с менеджера доступ к админке ровно в момент, когда его повысили в правах.
Выдаём доступ на срок:
\CUser::SetUserGroup($userId, [ ['GROUP_ID' => 5], // постоянная группа ['GROUP_ID' => $promoGroupId, 'DATE_ACTIVE_TO' => '31.12.2026 23:59:59'],]);// после этой даты членство перестаёт учитываться самоСрочное членство в группе удобнее любых агентов чистки просроченных доступов. Платформа сама перестаёт учитывать просроченную запись, а история выдачи остаётся видна в карточке пользователя.
Назначаем группу после события:
\Bitrix\Main\EventManager::getInstance()->addEventHandler('sale', 'OnSaleOrderPaid', static function (\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = (int)$order->getUserId(); \CUser::SetUserGroup($userId, array_unique( array_merge(\CUser::GetUserGroup($userId), [CLIENT_GROUP_ID]))); });Событие срабатывает точнее и быстрее любого скрипта по расписанию. Покупатель попадает в группу клиентов сразу после оплаты, а не через сутки, и видит свои цены уже на следующей странице.
Проверяем состав группы:
$rs = \CUser::GetList('ID', 'ASC', ['GROUPS_ID' => [$dealerGroupId], 'ACTIVE' => 'Y'], ['FIELDS' => ['ID', 'LOGIN', 'EMAIL']]);while ($row = $rs->Fetch()) { printf("%d %s\n", $row['ID'], $row['LOGIN']); }// тот же отбор работает и в выгрузке пользователей в файлТипичные проблемы
После выдачи новой группы человек потерял прежний доступ.
Список групп записан заново, а прежние группы в него не попали. Новую группу добавляют к текущему списку, полученному перед самой записью.
Доступ пропал сам по себе через месяц.
У членства в группе стояла дата окончания, и платформа перестала его учитывать. Сроки членства смотрят в списке групп пользователя вместе с датами.
Запрет в одной группе не срабатывает.
Права складываются из всех групп, и более широкое право побеждает запрет. Доступ ограничивают, убирая пользователя из широкой группы, а не добавляя запрет.
Новый клиент попадает в группу только на следующий день.
Группа назначается скриптом по расписанию, а не обработчиком нужного события платформы. Событие оплаты или регистрации выдаёт группу сразу и без задержки.
Пользователь в нужной группе, а цены прежние.
Страница отдаётся посетителю из кэша, собранного для прежнего набора его групп. Кэш витрины и композитную копию страницы сбрасывают после смены групп покупателя.
Частые вопросы
Как права складываются из нескольких групп?
Побеждает самое широкое право среди всех групп пользователя. Поэтому лишняя группа с широким доступом опаснее, чем отсутствие запрета.
Можно ли выдать группу на месяц?
Да, у членства есть даты начала и окончания. После даты окончания платформа перестаёт учитывать членство сама, чистить его не нужно.
Почему после смены групп ничего не изменилось?
Чаще всего страница пришла из кэша, собранного для прежних групп. Помогает сброс кэша витрины, а на композитных страницах - и композитной копии.
Где смотреть, кто состоит в группе?
Выборкой пользователей с отбором по группе или в интерфейсе самой группы. Выборка удобнее: её можно сохранить как отчёт и повторять.
Что делать с группой «все пользователи»?
Считать её базовым уровнем доступа и не выдавать ей ничего лишнего. Всё, что разрешено ей, разрешено и любому гостю сайта.
Смежное
- Права доступа на практике - оглавление подтемы
- Роли менеджеров: что видит и что может в админке - какие группы заводят для сотрудников
- Права на инфоблок и заказы: выдача из интерфейса и кодом - что группы дают на данные
- Права не применяются: разбор причин - когда группа есть, а доступа нет
- Дилерский доступ: свои цены, свой каталог, документы - группа как признак оптовика
- Типы цен: розница и опт, права групп, цена по количеству - цены по группам покупателей
- Синхронизация пользователей с внешней системой: ключ, группы, увольнения - группы при регулярном обмене
- Пользователи, группы и права доступа - устройство доступа целиком
- Учётная запись изнутри - где связь с группой стоит среди остального состава записи