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