Права в Битрикс24: как проверить доступ менеджеров и интеграций
Скрытый раздел карточки не доказывает запрет доступа, а успешный тест администратора не подтверждает работу менеджера. Разбираем матрицу действий, роли и проверку обмена.
После изменения прав менеджер перестал видеть соседнюю воронку в меню. Команда считает задачу закрытой. Через неделю выясняется, что карточка по прямой ссылке всё ещё открывается, а интеграция продолжает выгружать сведения от имени сотрудника с широкими полномочиями. Изменение интерфейса и ограничение действия оказались разными вещами.
Настройка прав в Битрикс24 начинается с вопроса: кто, над каким объектом и какое действие должен выполнить. Ниже — методика проверки для компании с двумя отделами продаж и обменом с внешней системой. Это предлагаемая организация работы, а не описание инцидента у клиента.
Названия должностей слишком общие. «Менеджер работает со своими клиентами» не отвечает, может ли он экспортировать их контакты, удалять сделку, менять ответственного или видеть карточку после передачи в другой отдел. Каждое существенное действие нужно сформулировать отдельно.
Возьмите несколько контрольных объектов: собственную сделку сотрудника, сделку коллеги, запись другого отдела и закрытую сделку. Для каждого определите ожидаемый результат чтения, изменения, удаления и экспорта. Отдельно опишите руководителя, временного заместителя и интеграцию.
Участник
Рабочая потребность
Что проверить отдельно
Менеджер
Вести назначенные сделки
Чужая карточка и экспорт
Руководитель
Контролировать свой отдел
Соседний отдел и смена стадии
Заместитель
Временно принять работу коллеги
Срок и окончание доступа
Интеграция
Читать и изменять согласованные данные
Лишние объекты и операции
Таблица — пример постановки задачи, а не готовая настройка. У компании могут быть другие границы: продукт, филиал, юридическое лицо. Ответственный по карточке и организационная принадлежность не всегда совпадают, поэтому правила стоит проверить на реальных типах записей.
В справке о ролевой модели CRM описана настройка прав по объектам и действиям. Возможности зависят от тарифа. Роли могут назначаться сотрудникам и группам, поэтому полезно составить перечень всех назначений проверяемого человека, включая отделы и рабочие группы.
Не оценивайте итоговый доступ только по одной роли с понятным названием. У сотрудника может быть ещё одно назначение или исключение на стадии. Механику пересечений следует сверять с официальным разбором конфликтов прав . Проверка должна включать фактическое действие под нужной учётной записью.
У стадий есть собственные настройки и наследование общих правил. Если доступ меняется после перехода сделки, выясните, какая стадия сработала и кто должен продолжить работу. Ограничение, которое случайно отрезало исполнителя после передачи в работу, мешает процессу даже при формально строгой матрице.
Не принимайте внешний вид карточки за защиту данных #
Общий вид карточки помогает расположить поля для удобной работы. Но отсутствие поля на экране само по себе не доказывает запрет чтения. Проверяйте отдельно настройку представления и разрешённые действия с объектом. У интерфейса и механизма доступа разные задачи.
Если требование звучит как «сотрудник не должен получать определённые сведения ни одним способом», проверьте все используемые каналы: карточку, список, выгрузку, отчёт и интеграцию. Нельзя обещать защиту отдельного поля, исходя только из возможности убрать его из формы. Сначала подтверждают доступные механизмы именно вашей редакции и инструмента.
То же относится к документам и задачам. Ссылка из сделки может вести к файлу с собственными настройками доступа или к задаче с другим составом участников. Просмотр самой сделки ещё не подтверждает ни доступ к вложению, ни его запрет. Для каждого связанного объекта нужна своя контрольная проверка.
Для REST-вызова имеют значение и разрешения приложения или вебхука, и права пользователя. В документации REST 3.0 это указано как два отдельных условия проверки. Наличие доступа к CRM в настройках приложения не означает возможность прочитать любую карточку.
В карте интеграции запишите владельца авторизации, используемые объекты, разрешённые операции и зависимость от подразделения. Для сервисного обмена определите устойчивую учётную запись и ответственного за её сопровождение в рамках доступного механизма авторизации. Не оставляйте эту зависимость неявной в личной учётной записи случайного сотрудника.
Если обмен получает отказ, не расширяйте права до административных только ради исчезновения ошибки. Найдите конкретную операцию и контрольный объект. Возможно, обработчик пытается менять поле вне согласованной задачи или читать запись другого направления. Расширение доступа в таком случае скрывает ошибку архитектуры.
Изменение владельца или отзыв старой авторизации также нужно проверить как рабочий сценарий. Новое подключение сначала подтверждают на разрешённых объектах, затем выключают прежнее. Токены и секретные адреса вебхуков в отчёт проверки не включают.
Положительная проверка отвечает, может ли менеджер выполнить нужное действие. Отрицательная — сможет ли он выполнить запрещённое. Нужны обе. Проверяйте прямую ссылку, поиск, список и разрешённую выгрузку там, где они входят в работу команды.
Тест администратора полезен для диагностики, но не заменяет тест сотрудника. Используйте выделенных проверочных пользователей или согласованную процедуру участия сотрудников. Фиксируйте объект, действие, ожидаемый и фактический результат. Формулировка «права проверены» без этих сведений не объясняет границы контроля.
Особое внимание уделите изменению состояния: назначению нового ответственного, переходу стадии, переводу сотрудника в другой отдел и окончанию замещения. Доступ должен соответствовать новой ситуации, а незавершённые дела — оставаться у предусмотренного исполнителя.
Для интеграции проведите тот же набор через её реальную авторизацию. Прочитанная карточка и успешно изменённая карточка — разные проверки. Массовый обмен включают после проверки узкой выборки и журнала отказов, чтобы пропущенные записи не маскировались общим сообщением об успехе.
Для простой команды это может быть достаточно. Но временный заместитель, руководитель нескольких направлений и сервисный обмен часто имеют отличающиеся задачи. Дополнительная роль оправдана наблюдаемым различием полномочий, а не желанием заранее создать все возможные комбинации.
Что делать, если после ограничения перестали работать роботы? #
Проверить конкретное действие, контекст выполнения и доступ к его объектам. Сначала восстановите необходимую бизнес-операцию в согласованных границах. Возврат широких прав всей группе не объяснит, какая зависимость была пропущена.
NetLabCS поможет составить матрицу действий и проверить роли при настройке и доработке Битрикс24 . Для обсуждения задачи подготовьте пример разрешённой и запрещённой операции, структуру отделов и перечень подключений. По ним определим реальные границы проверки.
