Ситуация, когда несколько сотрудников включены в одну и ту же Группу доступа, но при этом один из них получает ошибку «Объект не обнаружен» или «Нарушение прав доступа», является классической для конфигураций на базе ERP (включая «1С:Комплексная автоматизация 2.5» и «1С:Управление торговлей 11»). На первый взгляд кажется, что права должны быть идентичными, однако современная архитектура 1С накладывает множество дополнительных условий на итоговую матрицу полномочий.
В этой статье мы подробно разберем, почему возникают такие расхождения, и разработаем пошаговый план диагностики системы. Мы пройдем путь от самых простых «пользовательских» ошибок до сложных технических нюансов работы механизма RLS (Record Level Security). Для быстрого выявления расхождений можно использовать обработку для сравнения прав пользователей.
Прежде чем углубляться в программный код или сложные настройки метаданных, проанализируем состояние клиентского приложения. 1С активно кэширует конфигурацию и данные пользователя для ускорения работы. Иногда кэш «залипает», и система продолжает применять старые ограничения, даже если в базе данных права уже изменены.
Рассмотрим, как правильно очистить кэш:
Механизм RLS (ограничение доступа на уровне записей) — это наиболее вероятная причина проблемы. В отличие от обычных ролей, RLS проверяет не просто «можно ли открывать заказы», а «можно ли открывать именно ЭТОТ заказ».
Выясним, какие индивидуальные фильтры могут накладываться на пользователя:
В современных версиях 1С данные RLS для ускорения работы записываются в специальные вспомогательные таблицы (регистры сведений). Если регламентное задание по обновлению этих данных не отработало, права пользователя могут «зависнуть» в промежуточном состоянии.
Разберем, как запустить обновление вручную:
Также полезно проверить регистр сведений ТаблицыГруппДоступа. Мы можем сделать это через «Все функции» (или «Функции для технического специалиста»), чтобы убедиться, что запись о нашем пользователе и его роли в группе «Менеджеры по продажам» присутствует в актуальном состоянии.
Иногда администраторы допускают ошибку, назначая роли пользователю напрямую через Конфигуратор, минуя интерфейс «Группы доступа» в режиме 1С:Предприятие. Это приводит к конфликту логики.
Проанализируем ситуацию: механизм БСП (Библиотеки стандартных подсистем) при каждом входе пользователя или изменении его настроек в пользовательском режиме пытается синхронизировать список ролей. Если вы добавили роль вручную, система может либо игнорировать ее при проверке RLS, либо вовсе снять ее при очередном обновлении профиля. Важно: все права в КА 2.5 должны назначаться только через профили и группы доступа в пользовательском режиме.
В «1С:Комплексная автоматизация» часто включается опция «Разрешить чтение/изменение только своих документов». Посмотрим, как это работает:
Если в профиле группы доступа установлена такая настройка, система сравнивает текущего пользователя с полем Менеджер или Ответственный в документе Заказ клиента. Если пользователь не указан как ответственный и не входит в группу руководителей этого подразделения, он получит отказ в доступе. Выясним, совпадает ли Основное подразделение в карточке пользователя с подразделением, указанным в проблемном заказе. Для проверки полномочий сотрудника по конкретному документу подойдёт обработка для анализа прав доступа на объект базы данных.
Если в вашей базе используются расширения, они могут содержать собственные роли или измененные запросы RLS. Рассмотрим пример кода, который может быть внедрен в расширение и влиять на доступ:
// Пример логики в расширении, которая может ограничивать доступ
&После("ПриЧтенииНаСервере")
Процедура Расш1_ПриЧтенииНаСервере(ТекущийОбъект)
Если ТекущийОбъект.СуммаДокумента > 100000 И НЕ РольДоступна("ПолныеПрава") Тогда
// Логика дополнительной проверки
КонецЕсли;
КонецПроцедуры
Если подобная проверка срабатывает только для определенных сумм или видов операций, может возникнуть иллюзия, что у пользователя «просто нет прав», хотя на самом деле это специфическая логика расширения.
Проанализируем справочник Пользователи на наличие дублей. Бывают случаи, когда создано две карточки с одинаковым именем: одна — для обычной работы, другая — для обмена данными или внешнего доступа. Убедимся, что пользователь авторизуется именно под той учетной записью, которую мы настраиваем.
Также проверим статус «Внешний пользователь». Для внешних пользователей (например, представителей клиентов или дилеров) действуют совершенно иные алгоритмы проверки прав, даже если они включены в общие группы доступа. Доступ для них обычно сильно ограничен на уровне программного кода в модулях менеджеров объектов.
Если после очистки кэша и обновления прав доступа проблема сохраняется, мы рекомендуем воспользоваться стандартным отчетом: «Анализ прав доступа». Его можно найти в карточке пользователя. Этот отчет наглядно показывает, из какой группы доступа пришло конкретное право и какое именно ограничение RLS (по организации, по складу или по партнеру) блокирует работу с документом.
Совместный анализ настроек RLS и регламентных заданий в 99% случаев позволяет выявить причину «неравноправия» пользователей внутри одной группы.