Обновление крупных конфигураций, таких как 1С:ERP, особенно если в них присутствуют доработки, — сложный процесс, сопряженный с рисками. Как показывает опыт обновления сильно доработанных конфигураций, одной из наиболее неочевидных и трудно диагностируемых проблем является внезапная потеря прав доступа у пользователей к документам, которые они сами же и создают. Рассмотрим подробно ситуацию, когда после обновления базы данных пользователи сталкиваются с ошибкой «У пользователя недостаточно прав для исполнения операции над базой данных» при записи документов, и разберем, как восстановить корректную работу механизма ограничения доступа на уровне записей (RLS).
Давайте проанализируем ситуацию, с которой мы можем столкнуться. После установки обновления (в данном случае переход на версию 2.5.17.103) поведение системы меняется следующим образом:
ЗаявкаНаРасходованиеДенежныхСредств).Такое поведение указывает на то, что проблема кроется не в простых ролях (Role), а именно в механизмах расчета прав доступа в производительном режиме.
Чтобы понять причину сбоя, нам необходимо углубиться в то, как работает подсистема «Управление доступом» из Библиотеки Стандартных Подсистем (БСП), на которой построена 1С:ERP.
В "классическом" режиме RLS система рассчитывает права "на лету" при каждом запросе к данным. Это создает высокую нагрузку. В производительном режиме система использует заранее рассчитанные ключи доступа (дескрипторы). Эти ключи хранятся в специальных регистрах сведений (например, КлючиДоступаКРегистрам, КлючиДоступаКОбъектам).
Когда вы записываете документ, система должна понять: нужно ли для этого объекта создавать ключ доступа? Для этого используются специальные объекты метаданных — Определяемые типы (DefinedTypes).
В конфигурации существуют ключевые определяемые типы, которые служат "списком регистрации" для системы доступа. Рассмотрим наиболее важный для документов:
DefinedType.ВладелецЗначенийКлючейДоступаДокумент
В этот тип должны входить ссылки на все документы, для которых должен работать механизм ограничения прав доступа (RLS). Если документ исключен из этого типа, подсистема считает, что рассчитывать права для него не нужно.
Почему возникает ошибка именно после обновления? Разберем механику процесса обновления конфигурации (Merge). Чтобы не тратить время на тысячи кликов в интерфейсе сравнения, специалисты иногда используют методы группового изменения режима поддержки по подсистемам, однако при этом сохраняется риск некорректного объединения типов.
Когда мы обновляем доработанную (нетиповую) конфигурацию, происходит трехстороннее сравнение объектов: 1. Старая конфигурация поставщика. 2. Новая конфигурация поставщика. 3. Наша текущая конфигурация (с доработками).
Определяемый тип ВладелецЗначенийКлючейДоступаДокумент часто модифицируется при внедрении (туда добавляются самописные документы). В то же время, фирма "1С" в новых релизах добавляет туда свои новые документы или меняет состав существующих.
Суть проблемы: При объединении конфигураций специалист, выполняющий обновление, может случайно выбрать вариант "Взять из новой конфигурации поставщика" или некорректно объединить списки типов. В результате:
Давайте проследим, что происходит в момент записи документа при некорректно настроенном определяемом типе:
DefinedType.ВладелецЗначенийКлючейДоступаДокумент. Из-за ошибки обновления тип там отсутствует. Система "думает": "Ок, этому документу RLS не нужен" и не создает запись в регистре ключей доступа.ЛОЖЬ. Платформа видит, что пользователь пытается прочитать объект, к которому (согласно таблицам RLS) у него нет доступа. Генерируется исключение нарушения прав.Именно поэтому документ создается (запись прошла), но пользователь его "не видит" и получает ошибку (чтение заблокировано).
Теперь, когда мы выяснили причину, перейдем к исправлению ситуации. Нам потребуется доступ в режим Конфигуратора.
Откройте конфигуратор и найдите в дереве метаданных ветку Определяемые типы (DefinedTypes). На этом этапе могут быть полезны сторонние инструменты для просмотра прав и групп доступа на объекты (см. анализ и расшифровка прав доступа и ролей RLS), позволяющие быстро сориентироваться в структуре профилей и ролей. Нам необходимо проверить следующие типы:
ВладелецЗначенийКлючейДоступа (для справочников и ПВХ)ВладелецЗначенийКлючейДоступаДокумент (для документов)ВладелецЗначенийКлючейДоступаНаборЗаписей (для регистров)ВладелецЗначенийКлючейДоступаОбъект (общий, если используется)Двойным кликом откройте свойства типа ВладелецЗначенийКлючейДоступаДокумент. Внимательно просмотрите список типов, входящих в него.
Действия:
1. Убедитесь, что галочками отмечены все документы, для которых должен работать RLS.
2. Если вы видите, что список подозрительно пуст или в нем отсутствуют документы, с которыми возникают ошибки (например, ЗаявкаНаРасходованиеДенежныхСредств), необходимо восстановить состав типа.
3. Лучший способ — сравнить конфигурацию с конфигурацией поставщика того же релиза (Конфигурация -> Поддержка -> Настройка поддержки -> Сравнить с конфигурацией поставщика) и убедиться, что вы взяли все типовые объекты.
4. Также вручную добавьте ваши собственные (нетиповые) документы, если они должны ограничиваться правами доступа.
После восстановления состава определяемых типов сохраните конфигурацию и обновите конфигурацию базы данных (F7).
Просто исправить метаданные недостаточно. База данных уже содержит документы без сформированных ключей ("битые" ссылки с точки зрения RLS). Нам нужно заставить систему пересчитать их.
Запустите программу в режиме 1С:Предприятие под пользователем с полными правами (Администратор).
Более надежный способ — использовать штатную обработку обновления. Откройте Функции для технического специалиста (Shift+F11, если включено в параметрах) -> Обработки -> Управление доступом (или Результаты обновления программы -> Обновление доступа).
В этой обработке вы можете запустить пересчет прав. Рекомендуется выбрать вариант "Обновить" именно для тех видов документов, с которыми были проблемы, чтобы не пересчитывать всю базу, что может занять длительное время.
Если после выполнения вышеописанных действий проблема сохраняется, возможно, дело в зависшей очереди обновлений прав. Рассмотрим, где это проверить.
В производительном режиме обновление прав происходит в фоновом режиме. Если фоновое задание "упало" или очередь забита, новые права не применятся.
Посмотрите содержимое регистра сведений:
РегистрСведений.ОчередьОбновленияПравДоступа
Если в этом регистре тысячи записей и их количество не уменьшается, значит, фоновое регламентное задание по обновлению прав не работает или работает с ошибками. Проверьте журнал регистрации на наличие ошибок в фоновых заданиях.
Для точечной проверки конкретного документа и пользователя используйте отчет Анализ прав доступа (доступен через Все функции -> Отчеты -> Управление доступом -> Анализ прав доступа). Если стандартного отчета недостаточно, можно применить детальный анализ прав доступа на объект базы данных с помощью внешней обработки, которая покажет права с учетом RLS в удобном виде.
В отчете выберите:
Также рекомендуем использовать специализированную обработку для анализа прав доступа к объекту (поможет детальный анализ прав доступа и ролей RLS), которая наглядно демонстрирует роли, определяющие права к выбранному объекту, и профили групп доступа, в которые они включены.
Ошибка "Недостаточно прав" при записи новых документов в ERP после обновления чаще всего вызвана тем, что при объединении конфигураций был очищен или некорректно объединен определяемый тип ВладелецЗначенийКлючейДоступаДокумент. Из-за этого механизм производительного RLS перестает генерировать ключи доступа для новых объектов.
Для исправления необходимо:
ВладелецЗначенийКлючейДоступаДокумент.Всегда внимательно проверяйте состав определяемых типов при обновлении нетиповых конфигураций, чтобы избежать подобных проблем в будущем.