Как ограничить права на изменение конкретного справочника в 1С (на примере «Типы связей» в Документообороте 2.1)

От:

Проблема: Пользователь, которому не должны быть доступны изменения в критичных справочниках, имеет возможность редактировать данные (например, справочник «ТипыСвязей» (e1cib/list/Справочник.ТипыСвязей).

Это выявлено в протоколе работы

Цель: Точечно отозвать права на изменение конкретного объекта метаданных, не нарушая общую работу пользователя и не затрагивая других сотрудников.

Шаг 0: Диагностика. Где пользователь получает права?

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

  1. Анализ через регистр сведений «Права ролей»: Используем обработку «Контроль доступа: Просмотр и редактирование прав» или открываем регистр сведений «Права Ролей» напрямую.

2. Поиск роли: Находим в списке прав объект метаданных «Справочник.ТипыСвязей». Мы увидим все роли, у которых есть права на него (Изменение, Добавление).

3. Выявление пути: Это кропотливая работа. Придётся просмотреть полномочия, которые привязаны к проблемному пользователю.

В нашем случае, например, роль «ДобавлениеИзменениеНСИ» включена не напрямую, а через цепочку: 

Рабочая группа «Делопроизводители» — Полномочие «Делопроизводители» — Роль «ДобавлениеИзменениеНСИ».

Рабочая группа «Делопроизводители»

Полномочия «Делопроизводители»

Роль «Добавление и изменение НСИ»

В регистре «Права ролей» можно попробовать ограничить права.  Для начала включаем возможность редактирования.

Открываем нужную запись – «Еще» — «Включить возможность редактирования»

Затем снимаем галки «Изменение» и «Добавление»

Подтверждаем командой «Записать и закрыть».

Важный вывод: Роль общая. Её прямая правка в регистре «Права ролей» (снятие галок «Изменение» и «Добавление» с последующей записью) часто не работает корректно, так как она является частью конфигурации и не может быть изменена.

Варианты решения

Вариант 1: Быстрая коррекция через интерфейс (Частичное решение)

Действие: В карточке пользователя или в настройках полномочия «Делопроизводители» снять галочку у роли «ДобавлениеИзменениеНСИ».

Недостатки этого решения:

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

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

Вариант 2: Корректное решение через Конфигуратор (Создание специализированной роли)

Этот метод позволяет точечно изменить права без побочных эффектов.

Шаг 1: Подготовка в Конфигураторе

  1. Запускаем Конфигуратор 
  2. Подключаемся к хранилищу конфигурации (изменения в расширении выполнить сложнее требуется основная конфигурация).
  3. Захватываем корневой объект.

Шаг 2: Создание копии роли

  1. В дереве конфигурации находим роль «ДобавлениеИзменениеНСИ».

2. Скопируем её (ПКМ — «Скопировать»).

Даём новой роли уникальное имя, например, «корпДобавлениеИзменениеНСИ» (с префиксом).

Шаг 3: Редактирование прав новой роли

  1. Открываем свойства новой роли.
  2. Переходим на вкладку «Права».
  3. Находим в дереве объектов метаданных «Справочники» — «ТипыСвязей».
  4. Снимаем флажки с прав «Добавление», «Изменение» и «Удаление».
  1. Оставляем активными только права «Чтение» и «Просмотр». Это гарантирует, что данные справочника будут видны, но не редактируемы.

Шаг 4: Обновление конфигурации и настройки доступа

  1. Загружаем обновленную конфигурацию в базу данных.
  2. Переходим в режим «Предприятие».
  3. Переходим в настройки полномочий
  4. В составе полномочия «Делопроизводители» меняем старую роль «ДобавлениеИзменениеНСИ» на новую — «корпДобавлениеИзменениеНСИ».

Шаг 5: Проверка и завершение

  1. Входим в систему под пользователем, на которого распространяется измененное полномочие.
  2. Пробуем открыть справочник «Типы связей» и изменить существующую или добавить новую запись. Действия должны быть заблокированы (форма будет недоступна для редактирования или кнопки неактивны).
  1. Если проверка прошла успешно, загружаем обновлённую конфигурацию в рабочую базу для всех пользователей.
  2. Для гарантии актуальности кэша прав можно обновить регистр сведений «Права» 

Итог и рекомендации

  • Вариант 1 (через интерфейс) — быстро, но «грубо» и часто небезопасно для бизнес-процессов. Используйте только для экстренного блокирования.
  • Вариант 2 (через конфигуратор) — методически правильный, точечный и безопасный способ. Требует прав разработчика и доступа к хранилищу конфигурации.

Рекомендуемая последовательность действий:

  1. Всегда начинаем с диагностики (Шаг 0), чтобы понять полную цепочку назначения прав.
  2. Для постоянного и корректного ограничения выбираем Вариант 2.
  3. После любых изменений в ролях обязательно проводим тестирование под учётной записью пользователя, чьи права менялись.

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


Комментарии закрыты