Как ограничить видимость элементов и групп справочника по организации или ответственному в 1С

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

Метод 1. Использование механизма RLS (Record Level Security)

Это наиболее правильный и надежный способ с точки зрения архитектуры системы. RLS — это ограничение доступа на уровне записей. Даже если пользователь попытается открыть список через универсальную обработку или консоль запросов, он все равно не увидит «чужие» данные, так как ограничение накладывается на уровне SQL-запроса платформой.

Разберем по шагам, как настроить RLS для справочника Сотрудники:

1. Создание параметра сеанса. Сначала нам нужно где-то хранить информацию о том, к какой организации «привязан» текущий пользователь. Создадим ПараметрСеанса с именем ТекущаяОрганизация.
2. Инициализация параметра. В модуле сеанса необходимо прописать заполнение этого параметра при входе пользователя в систему. Проанализируем ситуацию: мы можем найти сотрудника, связанного с текущим пользователем ИБ, и получить его организацию.
   Скопировать код

   
   Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
       // Находим организацию текущего пользователя
       ОрганизацияПользователя = НайтиОрганизациюПо ТекущемуПользователю(); 
       ПараметрыСеанса.ТекущаяОрганизация = ОрганизацияПользователя;
   КонецПроцедуры
   

3. Настройка роли. Создадим новую роль (например, «ПользовательОграниченный»). В дереве объектов найдем наш справочник Сотрудники. На вкладке «Права» выберем право «Чтение».
4. Создание шаблона ограничения. Чтобы не писать один и тот же код для разных справочников, создадим шаблон ограничения (например, с именем «ПоОрганизации»). Текст шаблона будет выглядеть так: ГДЕ Организация = &ТекущаяОрганизация
5. Применение ограничения. В колонке «Ограничение доступа к данным» выберем наше право «Чтение», укажем поле (можно оставить «Прочие поля») и пропишем вызов шаблона.

Важный нюанс: Если справочник иерархический и вы хотите ограничить видимость групп, убедитесь, что в условии RLS учитывается логика иерархии. Если пользователь не имеет прав на чтение родительской группы, элементы внутри нее могут отображаться некорректно. Рассмотрим вариант использования конструкции В ИЕРАРХИИ, однако помните, что для «чистой» и быстрой базы лучше использовать простое равенство по реквизиту Организация.

Метод 2. Программная установка отбора в обычных формах

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

Рассмотрим реализацию в модуле формы списка справочника Сотрудники в событии ПриОткрытии:

Процедура ПриОткрытии()
    // Определяем организацию, по которой нужно фильтровать
    НужнаяОрганизация = ПолучитьОрганизациюТекущегоПользователя();
    
    // Устанавливаем отбор в элементе управления СправочникСписок
    // СправочникСписок - это стандартное имя табличного поля на форме
    Попытка
        ЭлементОтбора = СправочникСписок.Отбор.Организация;
        ЭлементОтбора.Значение = НужнаяОрганизация;
        ЭлементОтбора.Использование = Истина;
        ЭлементОтбора.ВидСравнения = ВидСравнения.Равно;
        
        // Чтобы пользователь не мог отключить отбор вручную:
        ЭлементОтбора.Доступность = Ложь;
    Исключение
        Сообщить("Не удалось установить фильтр по организации");
    КонецПопытки;
КонецПроцедуры

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

Метод 3. Хранение прав в Регистре Сведений

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

В этом случае рекомендуется создать периодический Регистр Сведений НастройкиПравДоступа с измерениями Пользователь и ОбъектДоступа (тип — СправочникСсылка.Организации). Это позволит:

1. Назначать пользователю несколько доступных организаций.
2. Хранить историю изменений (кто и когда дал доступ).
3. Использовать эти данные в RLS через вложенный запрос.

Посмотрим на пример запроса в RLS с использованием регистра сведений:

Сотрудники ГДЕ Сотрудники.Организация В 
    (ВЫБРАТЬ Рег.ОбъектДоступа 
     ИЗ РегистрСведений.НастройкиПравДоступа КАК Рег 
     ГДЕ Рег.Пользователь = &ТекущийПользователь)

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

Сравнение подходов

Разберем кратко преимущества и недостатки каждого метода:

1. RLS: Плюсы — максимальная безопасность, работает на уровне платформы во всех списках, отчетах и запросах. Минусы — может снижать производительность при очень больших объемах данных и сложных запросах.
2. Программный отбор: Плюсы — простота реализации, не требует настройки ролей. Минусы — нужно прописывать в каждой форме списка и выбора, легко обходится пользователем.
3. Функциональные опции: Хотя они больше про интерфейс (скрыть колонку, кнопку), в сочетании с параметрами сеанса они позволяют сделать интерфейс максимально чистым для конкретного ответственного.

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