В процессе сопровождения конфигурации 1С:Комплексная автоматизация 1.1 (работающей на обычных формах) разработчики часто сталкиваются с нестандартными требованиями безопасности со стороны руководства. Одно из таких требований — полностью скрыть документы прошлых периодов от просмотра пользователями, сохранив при этом их права на работу в текущем периоде. Стандартный механизм даты запрета редактирования здесь не помогает, так как он лишь блокирует изменение данных, оставляя их доступными для чтения.
В этой статье мы подробно разберем, как решить эту задачу. Мы проанализируем распространенные заблуждения, рассмотрим правильную настройку ограничений на уровне записей (RLS) без нарушения расчета остатков в отчетах, изучим программные методы блокировки и обсудим радикальные, но наиболее надежные архитектурные подходы.
Среди разработчиков 1С существует устойчивый миф: если закрыть доступ к документам прошлого периода через RLS, то во всех отчетах «поплывут» или пропадут начальные остатки. Выясним причину этого заблуждения. Ошибки с расчетом остатков возникают только в том случае, если разработчик накладывает ограничение по дате одновременно и на документы, и на регистры накопления (или бухгалтерии).
Разберем по шагам правильный алгоритм настройки RLS, при котором остатки будут рассчитываться абсолютно корректно, а сами документы за прошлый период станут невидимыми:
Чтение исключительно для объектов метаданных типа Документы.<Объект не найден...>. В списках документов эти записи также отображаться не будут.Для оптимизации работы RLS крайне не рекомендуется обращаться в запросах ограничений напрямую к константам. Это вызывает серьезное падение производительности базы данных, так как запрос к таблице констант будет выполняться для каждой проверяемой строки. Чтобы избежать блокировок и замедления работы, используем Параметры сеанса.
Рассмотрим пример реализации в коде. Сначала создадим параметр сеанса ДатаЗапретаПросмотра. В модуле сеанса пропишем его инициализацию при старте системы:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
// Получаем дату запрета из константы или персональных настроек
ДатаОграничения = Константы.ДатаЗапретаПросмотраДокументов.Получить();
Если ЗначениеЗаполнено(ДатаОграничения) Тогда
ПараметрыСеанса.ДатаЗапретаПросмотра = ДатаОграничения;
Иначе
ПараметрыСеанса.ДатаЗапретаПросмотра = '00010101'; // Без ограничений
КонецЕсли;
КонецПроцедуры
После этого в шаблоне ограничения RLS для документов на право Чтение прописываем лаконичное и быстродействующее условие:
ГДЕ Дата >= &ПараметрыСеанса.ДатаЗапретаПросмотра
Этот подход гарантирует высокую скорость работы базы данных и решает задачу сокрытия документов без побочных эффектов для регламентированной и управленческой отчетности.
Если по каким-то причинам внедрение RLS в рабочей базе нежелательно (например, конфигурация сильно кастомизирована и RLS вызывает конфликты блокировок на СУБД), мы можем реализовать ограничение программными методами на уровне интерфейса обычных форм.
Для этого нам понадобится решить две задачи: скрыть документы из списков динамического просмотра и заблокировать их открытие по прямым ссылкам.
Рассмотрим подробнее, как принудительно установить отбор в формах списков документов. Добавим обработчик события при открытии формы списка или реализуем это через общий модуль интерфейса:
Процедура ПриОткрытииФормыСписка(Форма) Экспорт
ДатаЗапрета = ПараметрыСеанса.ДатаЗапретаПросмотра;
Если ЗначениеЗаполнено(ДатаЗапрета) Тогда
// Находим элемент отбора по дате в динамическом списке
ОтборДаты = Форма.ДокументСписок.Отбор.Дата;
ОтборДаты.ВидСравнения = ВидСравнения.БольшеИлиРавно;
ОтборДаты.Значение = ДатаЗапрета;
ОтборДаты.Использование = Истина;
// Блокируем для пользователя возможность отключить данный отбор
Форма.ЭлементыФормы.ДокументСписок.НастройкаОтбора.Дата.Доступность = Ложь;
КонецЕсли;
КонецПроцедуры
Пользователь больше не сможет увидеть старые документы в общем списке, однако он все еще может попытаться открыть документ по ссылке из других документов или внешних обработок. Чтобы полностью перекрыть этот канал утечки информации, настроим блокировку открытия форм документов с помощью подписок на события.
Создадим подписку на событие ПередОткрытием для форм документов. В обработчике подписки пропишем следующий код:
Процедура ПередОткрытиемФормыДокумента(Источник, Отказ, СтандартнаяОбработка) Экспорт
// Проверяем, что документ уже записан в базу (не новый)
Если ЗначениеЗаполнено(Источник.Ссылка) Тогда
ДатаЗапрета = ПараметрыСеанса.ДатаЗапретаПросмотра;
Если ЗначениеЗаполнено(ДатаЗапрета) И Источник.Ссылка.Дата < ДатаЗапрета Тогда
Предупреждение("Доступ к документам прошлых периодов ограничен руководством компании!");
Отказ = Истина; // Блокируем открытие формы
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Этот способ достаточно прост в реализации, практически не влияет на общую производительность системы и позволяет гибко управлять правами доступа без изменения глобальных ролей пользователей.
Если перед нами стоит задача физически оградить определенных пользователей от конфиденциальных исторических данных, отличным решением будет создание распределенной информационной базы (РИБ) с фильтрацией по дате.
Проанализируем этот сценарий по шагам:
В результате пользователи подчиненного узла физически не имеют в своей базе старых документов — базы данных разделены, и утечка информации становится невозможной даже при наличии у пользователя полных прав в его локальной копии.
Когда руководство требует скрыть прошлые периоды «вообще везде и для всех, кроме нескольких человек», самым надежным и методологически верным решением является физическая свертка информационной базы.
Разберем данный процесс поэтапно:
После свертки рабочая база значительно уменьшается в объеме, начинает работать быстрее, а рядовые пользователи физически теряют доступ к детальной истории операций прошлых лет, так как этих документов в рабочей базе больше не существует. При этом остатки для текущей работы сохранены в полном объеме.