Доработка сайта на Битрикс и права доступа: как менять логику, не открывая лишнего

Доработка сайта на Битрикс и права доступа — это настройка видимости разделов, элементов и действий для конкретных групп пользователей. Чтобы не открыть лишнего, зафиксируйте матрицу «роль × раздел × действие» до и после изменения, проверьте каждую роль на стенде и выпускайте релиз только при наличии плана возврата.

Что именно считается доработкой с учётом прав доступа

Доработка сайта на Битрикс и права доступа — это не «переделать всю политику безопасности», а точечное изменение существующей модели. Задача появляется, когда новая функция, раздел или кнопка должны быть видны одним ролям и недоступны другим. Например, менеджеру нужен доступ к заявкам своего отдела, а редактору — только к текстам, но не к персональным данным клиентов.

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

Артефакт на выходе — матрица «роль × раздел × действие» в двух состояниях: до и после. Плюс чек-лист проверки под каждой ролью, включая гостя и администратора. Без этих двух документов приёмка превращается в спор о том, «так и было задумано или нет».

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

Шаблон постановки задачи: что должно быть в описании

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

Формулировка «сделать, чтобы менеджеры видели заявки» — недостаточна для постановки задачи. Из неё непонятно, все менеджеры или только своего отдела, видят ли они заявки других отделов, могут ли менять статус, экспортировать, удалять. Каждое из этих «или» — отдельное решение, которое влияет на объём работы.

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

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

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

Исходные данные и ответственные за решение

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

Ответственные распределяются так. Владелец процесса формулирует, что должно быть видно и кому. Аналитик или руководитель проекта переводит это в матрицу и проверяет, нет ли противоречий между ролями. Разработчик реализует изменение в существующей модели. Тестировщик или сам заказчик проходит чек-лист под каждой ролью. Администратор сайта подтверждает, что настройки групп не сломали другие сценарии.

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

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

Варианты реализации и критерии выбора

На практике выбор идёт между несколькими подходами. Они не «лучше» и «хуже» сами по себе — важна совместимость с текущей моделью проекта.

Первый вариант — использование существующих групп пользователей и их привязки к разделам (стандартные права доступа Битрикс). Подходит, когда новая функция ложится в уже описанные роли. Плюс: минимум изменений, понятная поддержка. Минус: если роли начнут дробиться, модель станет запутанной.

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

Третий вариант — разграничение на уровне действий внутри модуля (права на действия), когда раздел виден всем, но кнопки и операции доступны не всем. Подходит для сценариев, где важно не скрывать информацию, а ограничить операции.

Четвёртый вариант — проверка прав в момент выполнения действия (backend-валидация), а не только при отображении. Это защита от прямого обращения к операции в обход интерфейса. Такой подход сложнее, но он закрывает сценарии, которые не видны при обычном просмотре страниц.

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

Предметная последовательность действий

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

Сначала снимается текущее состояние: какие роли существуют, какие разделы и действия им доступны. Это фиксируется в матрице «до». Без этого шага невозможно доказать, что изменение не открыло лишнего.

Затем описывается целевое состояние — матрица «после». Расхождения между «до» и «после» и есть объём работы. Если расхождений больше, чем ожидалось, задача возвращается на уточнение, а не «доделывается по ходу» без пересмотра матрицы.

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

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

Затем изменение выпускается на рабочем сайте и проверяется повторно. Если что-то пошло не так, включается план возврата. О том, как выстроить сам выпуск, подробно рассказано в материале Релизы сайта Битрикс: как безопасно выпускать доработки.

Как собрать матрицу «роль × раздел × действие»

Матрица — это таблица, где строки — роли, столбцы — разделы и действия, а в ячейках — уровень доступа. Она заполняется дважды: до и после изменения. Разница между двумя таблицами и есть предмет приёмки.

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

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

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

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

Учебный пример: заявки отдела для менеджеров

Учебный пример: условная компания с несколькими отделами продаж ведёт заявки на сайте. Сейчас все менеджеры видят все заявки. Задача: менеджер видит только заявки своего отдела, руководитель отдела — заявки своего отдела и может менять статус, администратор — всё. Гость и зарегистрированный клиент не видят заявок вообще.

Входные условия: в проекте уже есть группы пользователей по отделам, заявки хранятся в отдельной сущности, у каждой заявки есть признак отдела. Текущая матрица «до»: все менеджеры видят все заявки, руководители видят все заявки, администратор видит всё. Целевая матрица «после»: менеджер — только свой отдел, просмотр; руководитель — свой отдел, просмотр и изменение статуса; администратор — всё; гость и клиент — ничего.

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

Проверка: под каждой ролью открывается список заявок и карточка заявки. Менеджер отдела А не должен видеть заявки отдела Б ни в списке, ни по прямой ссылке. Руководитель отдела А меняет статус только своих заявок. Администратор видит и меняет всё. Гость и клиент не получают доступа к заявкам. Отдельно проверяется, что экспорт и уведомления не раскрывают данные других отделов (например, через выгрузку в Excel или email-рассылку).

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

Чек-лист приёмки под каждой ролью

• Матрица «до» и «после» заполнена и согласована с владельцем процесса.
• Для каждой роли из матрицы есть отдельный сценарий проверки.
• Гость проверен: лишние разделы и действия недоступны.
• Администратор проверен: доступ к управлению сохранён.
• Прямые ссылки на скрытые разделы не открывают данные.
• Экспорт, уведомления и выгрузки не раскрывают данные других ролей.
• Смежные роли, не затронутые задачей, проверены на регрессию.
• Резервная копия сделана, план возврата зафиксирован.
• Изменение проверено на стенде до выпуска на рабочем сайте.
• После выпуска проведена повторная проверка по тем же сценариям.

Чек-лист подписывается тем, кто проверял, и хранится вместе с задачей. Это не бюрократия, а способ доказать, что проверка была, а не «вроде смотрели».

Типичные ошибки и ограничения

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

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

Ошибка третья: менять настройки сразу на рабочем сайте. Без стенда и резервной копии любая ошибка превращается в простой рабочих сценариев.

Ошибка четвёртая: не фиксировать решение. Через несколько месяцев никто не помнит, почему доступ устроен именно так, и следующая доработка ломает предыдущую логику.

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

Следующий шаг и связь с другими задачами

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

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

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