← На главную

При сопровождении конфигураций на платформе 1С:Предприятие 7.7 нередко возникает задача ограничить доступ конкретного пользователя к части информации: например, запретить новому сотруднику просматривать старых контрагентов, договоры и связанные с ними первичные документы, созданные до определенной даты. Поскольку в ядре платформы 7.7 отсутствует штатный механизм RLS (Row-Level Security), контроль прав осуществляется только на уровне метаданных целиком (чтение, запись, удаление объектов). Разберем архитектурные ограничения платформы и возможные практические подходы к решению этой задачи.

Ограничения платформы 1С 7.7 и почему штатные методы не дают полной защиты

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

1. Метод УстановитьОтбор(): Позволяет отфильтровать список в форме журнала или справочника только по тем реквизитам, для которых в конфигураторе взведен флаг «Отбор». Главное ограничение — метод работает исключительно на точное равенство одному значению (например, УстановитьОтбор("Ответственный", ТекПользователь)) и не позволяет задать условие сравнения по диапазону дат (>= или <=). Кроме того, пользователь может интерактивно отключить или изменить отбор.
2. Метод ИспользоватьСписокЭлементов(): Позволяет передать в форму списка объект типа СписокЗначений, сформированный запросом. Однако этот метод блокирует стандартные механизмы навигации, иерархию и сортировку, а при больших объемах данных приводит к повышенному расходу оперативной памяти.
3. Специфика файлового режима (DBF): Если база работает в файловом режиме, любая программная блокировка внутри 1С защищает лишь от случайного просмотра интерфейса. Любой пользователь, имеющий доступ к сетевой папке с базой данных, может открыть таблицы .dbf сторонними редакторами или драйверами прямого доступа.

Вариант 1. Программный контроль на уровне форм, журналов и отчетов

Рассмотрим комплексный подход к фильтрации интерфейса при помощи типовых средств встроенного языка. Для этого закрепим за пользователем границу разрешенного периода или ответственного менеджера.

Разберем по шагам реализацию схемы с отсечением по дате:

1. В справочнике пользователей создадим реквизит ДатаОграниченияВидимости типа «Дата».
2. В модуль каждого журнала документов в предопределенную процедуру ПриУстановкеИнтервала() добавим проверку:
   Скопировать код

   
   Процедура ПриУстановкеИнтервала(НачДата, КонДата, Способ)
       Если ПустоеЗначение(Конст.ТекущийПользователь.ДатаОграниченияВидимости) = 0 Тогда
           Если НачДата < Конст.ТекущийПользователь.ДатаОграниченияВидимости Тогда
               НачДата = Конст.ТекущийПользователь.ДатаОграниченияВидимости;
               Предупреждение("Просмотр документов ранее " + СокрЛП(НачДата) + " запрещен!");
           КонецЕсли;
       КонецЕсли;
   КонецПроцедуры
   

3. В форму каждого документа в процедуру ПриОткрытии() внедряем проверку даты документа:
   Скопировать код

   
   Процедура ПриОткрытии()
       Если ПустоеЗначение(Конст.ТекущийПользователь.ДатаОграниченияВидимости) = 0 Тогда
           Если ДатаДок < Конст.ТекущийПользователь.ДатаОграниченияВидимости Тогда
               Предупреждение("Доступ к документу ограничен политикой безопасности.");
               СтатусВозврата(0);
               Возврат;
           КонецЕсли;
       КонецЕсли;
   КонецПроцедуры
   

4. Во всех отчетах конфигурации в обработчике кнопки формирования принудительно корректируем начальную дату периода и фильтруем выборку по разрешенным объектам.

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

Вариант 2. Использование компоненты УРБД (распределенные базы)

Если требуется изолировать рабочее место нового сотрудника с минимальными изменениями конфигурации, разберем вариант с использованием компоненты «Управление распределенными информационными базами» (УРБД):

1. Создаем периферийный узел базы данных для изолированного сотрудника.
2. В правилах миграции метаданных устанавливаем режим передачи документов и справочников: из периферии в центр — передаются все создаваемые сотрудником данные; из центра в периферию — исторические документы и конфиденциальные справочники не передаются (миграция отключена или ограничена).
3. Общие базовые классификаторы настраиваем на миграцию во все базы.

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

Вариант 3. Перехват SQL-запросов и использование внешних компонент (для SQL-версий)

Для конфигураций, работающих под управлением MS SQL Server, существует возможность внедрить перехватчики запросов на уровне сетевого драйвера базы данных или библиотеки 1С++ / FormEx.

Выясним принцип работы этого механизма:

1. Перехват интерфейса (FormEx): Компонента позволяет перехватывать нажатия системных клавиш, блокировать контекстные меню табличных полей, запрещать пользователю интерактивное изменение интервала журналов и отключение отборов.
2. Модификация запросов на лету: При помощи перехватчиков SQL-запросов к таблицам _1SJOURN (журнал документов) и SC* (таблицы справочников) на уровне выполнения подставляется дополнительное условие: WHERE (DATE_TIME_IDDOC >= '20240101') AND ...
3. Виртуальные таблицы 1С++: Замена стандартных списков элементов на внешние табличные поля, формируемые через прямые SQL-запросы с жестко заданными параметрами фильтрации под конкретного пользователя.

Вариант 4. Архитектурное решение: Свертка (обрезка) базы

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

1. Создается полная архивная копия базы данных для руководства и бухгалтерии с полным доступом к историческим данным.
2. В рабочей базе выполняется свертка: удаляются исторические документы за прошлые годы, формируются входящие остатки на начало текущего периода, а неиспользуемые контрагенты и договоры физически удаляются из базы.
3. Новые сотрудники работают в актуальной облегченной базе, не имея физической возможности получить доступ к устаревшим данным.