Настройка ограничения доступа на уровне записей (RLS) — одна из наиболее востребованных задач в крупных компаниях, имеющих филиальную структуру. В конфигурации «1С:Бухгалтерия предприятия КОРП» (редакция 3.0) для этого предусмотрен стандартный механизм разделения по организациям. Однако на практике системные администраторы и программисты часто сталкиваются с неприятной ситуацией: после включения флажка «Ограничивать доступ на уровне записей» и настройки групп доступа пользователи начинают видеть только «свои» документы, но при попытке открыть их движения (проводки Дт/Кт) получают ошибку «Недостаточно прав», а Оборотно-сальдовая ведомость (ОСВ) формируется абсолютно пустой.
В этой статье мы подробно разберем, почему возникает эта проблема, как устроен механизм производительного RLS в современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) и рассмотрим пошаговые сценарии её диагностики и решения.
Для того чтобы эффективно решить проблему, проанализируем, как именно платформа 1С и БСП обрабатывают ограничение доступа в современных версиях. Начиная с БСП версии 3.x, в конфигурациях используется так называемый производительный режим RLS.
В старых версиях платформы при каждом обращении к базе данных система динамически дописывала сложные SQL-условия к запросам пользователей, что приводило к критическому снижению производительности СУБД. В производительном режиме логика кардинально изменилась:
Ключи доступа к объектам, Ключи доступа к регистрам, Обновление ключей доступа к данным и другие.Хозрасчетный (на основании которого строятся ОСВ и проводки документов) СУБД проверяет соответствие прав по уже готовым таблицам ключей доступа.Если вы только что включили галку ограничения доступа или изменили настройки профилей групп доступа, старые ключи аннулируются, а новые еще не рассчитаны. В этот переходный момент система считает, что у пользователя «нулевые» права на регистры. Как результат — документы видны (так как для них ключи могли успеть обновиться), а вот детальные движения по регистрам бухгалтерии заблокированы. Отсюда пустая ОСВ и ошибки при открытии Дт/Кт.
Прежде чем приступать к активным действиям, нам необходимо точно выяснить, на какой именно объект метаданных не хватает прав пользователю. Для этого выполним простую диагностику:
РегистрБухгалтерии.Хозрасчетный или вспомогательные регистры сведений, связанные с ключами доступа.Если мы убедились, что права отсутствуют именно из-за некорректной работы механизма RLS, перейдем к методам исправления ситуации.
В большинстве случаев штатные регламентные задания не успевают или не могут корректно завершить обновление служебных таблиц прав доступа из-за динамических обновлений или блокировок. Чтобы принудительно запустить пересчет всех вспомогательных данных БСП, нам необходимо перезапустить базу со специальным параметром.
Рассмотрим по шагам, как это сделать:
/c ЗапуститьОбновлениеИнформационнойБазы.Пример командной строки для файловой базы данных:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\MyBases\AccountingCorp" /N "Администратор" /P "ПарольАдмина" /C ЗапуститьОбновлениеИнформационнойБазы
После запуска система начнет выполнять все процедуры обновления, включая полную актуализацию регистров ограничений доступа. Это может занять некоторое время (от нескольких минут до часа в зависимости от объема базы данных). После завершения процесса зайдем под пользователем и проверим ОСВ — данные должны успешно отобразиться.
Иногда причиной сбоя работы механизмов RLS становится некорректное кэширование структуры метаданных на стороне клиента или сервера (особенно часто это проявляется после динамического обновления конфигурации).
Для устранения этой проблемы запустим тонкий или толстый клиент 1С с ключом очистки кэша:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\MyBases\AccountingCorp" /ClearCache
Если база работает в клиент-серверном режиме, также может потребоваться перезапуск службы сервера 1С:Предприятия для полной очистки серверного кэша метаданных.
Если у вас нет возможности монопольно заблокировать базу для запуска обновления, мы можем воспользоваться специализированными административными обработками, встроенными в Библиотеку стандартных подсистем.
Выполним следующие действия:
Заполнение данных для ограничения доступа и Обновление ключей доступа к данным.Если вы выполнили все вышеперечисленные процедуры обновления вспомогательных данных, но проводки по-прежнему недоступны, рассмотрим еще несколько возможных причин:
В некоторых операциях (например, при ручных корректировках или переносе данных) поле Организация в регистре бухгалтерии может оказаться незаполненным (содержать пустую ссылку или значение NULL). Стандартные шаблоны RLS блокируют отображение таких записей для всех пользователей, кроме администраторов с полными правами. В кастомных шаблонах RLS обязательно проверяйте обработку пустых ссылок:
ГДЕ Организация В (&ДоступныеОрганизации)
ИЛИ Организация = ЗНАЧЕНИЕ(Справочник.Организации.ПустаяСсылка)
ИЛИ Организация ЕСТЬ NULL
Если вы назначили пользователю несколько профилей групп доступа, содержащих разные RLS-ограничения на один и тот же регистр бухгалтерии, платформа будет объединять условия по правилу «ИЛИ». В результате формируется крайне сложный SQL-запрос к СУБД, который может приводить к ошибкам выполнения запроса или таймаутам на сервере. Постарайтесь минимизировать количество пересекающихся ограничений у одного физического лица.
Если в вашей конфигурации используются расширения или доработки, которые обращаются к проводкам документов напрямую, убедитесь, что в текстах запросов используется ключевое слово РАЗРЕШЕННЫЕ. Без него любой запрос к регистру бухгалтерии, содержащий хотя бы одну строку по чужой (недоступной пользователю) организации, вернет системную ошибку нехватки прав.
Пример корректного запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ХозрасчетныйДвижения.Субконто1,
ХозрасчетныйДвижения.Сумма
ИЗ
РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто(&НачалоПериода, &КонецПериода, , , ) КАК ХозрасчетныйДвижения
Проблема с пустой ОСВ и недоступностью проводок при включенном RLS почти всегда связана с неактуальностью или повреждением ключей доступа в служебных регистрах БСП. Оптимальным и самым быстрым решением является принудительный запуск базы с параметром /c ЗапуститьОбновлениеИнформационнойБазы, который гарантированно пересчитывает права доступа и восстанавливает корректную работу пользователей.