Почему у пользователей с одинаковыми ролями в 1С разные права доступа и как это исправить?

Ситуация, когда два пользователя имеют абсолютно идентичный набор ролей в Конфигураторе, но при этом один из них не может выполнить привычную операцию (например, записать документ Счет-фактура выданный), является классической проблемой для администраторов и разработчиков 1С. Особенно часто это проявляется в конфигурациях на обычных формах, таких как «Управление торговлей 10.3». В данной статье мы подробно разберем, как проанализировать ситуацию, где искать «скрытые» ограничения и какие инструменты использовать для диагностики.

Шаг 1. Анализ через Журнал регистрации

Первое, что мы должны сделать — это выяснить, на каком уровне происходит отказ: на уровне платформенных прав (метаданных) или на уровне программного кода. Для этого проанализируем Журнал регистрации. Рассмотрим последовательность действий:

1. Откроем Журнал регистрации (Сервис — Журнал регистрации).
2. Установим фильтр по пользователю, у которого возникает проблема.
3. Найдем событие с результатом «Отказ в доступе».

Если в журнале зафиксировано событие Доступ. Отказ в доступе. Документ.Счет-Фактура Выданный Действие: Изменение, значит, система безопасности платформы блокирует запись. Если же в журнале записей об отказе нет, но программа выдает окно с предупреждением, значит, ограничение зашито в программном коде конфигурации.

Шаг 2. Использование отладчика и поиск в коде

Часто разработчики внедряют проверки, которые не зависят от ролей. Это могут быть проверки по конкретным именам пользователей, по датам или по вхождению в определенные группы. Проанализируем программный код в модуле объекта документа или в модуле формы.

Рассмотрим пример кода, который может вызывать подобную проблему (аналогичный тому, что стал причиной в обсуждении):

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    Если Дата < '20210101' Тогда // Ошибка в коде: должна быть проверка текущего периода
        Если Не РольДоступна("ПолныеПрава") Тогда
            Сообщить("Редактирование документов за прошлый год запрещено!");
            Отказ = Истина;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

В данном случае, если у одного документа дата установлена корректно, а у другого ошибочно (например, прошлый год), пользователь без полных прав получит отказ, хотя роли у него могут быть такими же, как у коллеги.

Также стоит проверить наличие конструкций вида:

Если ИмяПользователя() = "Иванов" Тогда
    ЭтаФорма.ТолькоПросмотр = Истина;
КонецЕсли;

Хотя такой подход считается плохим тоном («хардкод»), в доработанных базах он встречается нередко. Выясним это с помощью глобального поиска (Ctrl+Shift+F) по метаданным документа.

Шаг 3. Регистр сведений «Дополнительные права пользователей»

В конфигурации «Управление торговлей 10.3» (и других на базе УПП 1.3) существует мощный механизм, дополняющий систему ролей. Это регистр сведений Дополнительные права пользователей. При копировании пользователя в справочнике эти настройки могут не скопироваться автоматически.

Проанализируем этот механизм:

• Перейдем в интерфейс «Администрирование пользователей» или найдем регистр через «Операции».
• Сравним настройки для обоих пользователей.
• Обратим внимание на такие флаги, как «Разрешить проведение документов будущим числом» или «Редактирование табличных частей».

Если у одного пользователя установлена галочка, а у другого — нет, их возможности будут различаться даже при одинаковой роли Менеджер по продажам.

Шаг 4. Проверка ограничений на уровне записей (RLS)

Если роли идентичны, но один видит/редактирует документ, а другой — нет, причина может крыться в RLS (Row Level Security). Это механизм, который ограничивает доступ к конкретным строкам таблиц (например, доступ только к одной Организации или одному Складу).

Разберем, как проверить RLS:

1. Проверим, в какие Группы пользователей включен новый сотрудник. В УТ 10.3 права RLS часто назначаются именно на группу.
2. Посмотрим настройки доступа в справочнике Группы доступа к контрагентам или Группы доступа к складам.
3. Если для нового пользователя не указана принадлежность к нужной группе, платформа выдаст «Отказ в доступе» при попытке изменить документ, относящийся к «чужому» складу или организации.

Шаг 5. Дата запрета редактирования

Проанализируем настройки даты запрета изменения данных. В 1С она может устанавливаться:

• Для всех пользователей.
• По конкретным пользователям.
• По группам пользователей.

Если для скопированного пользователя (или группы, в которую он входит) установлена персональная дата запрета, он не сможет редактировать документы ранее этой даты, в то время как другой пользователь будет работать без ограничений.

Шаг 6. Технические проблемы и кэш пользователя

Иногда проблема кроется не в настройках, а в техническом сбое платформы. Кэш метаданных на локальном компьютере может «забаговать» и хранить неверную информацию о правах. Выясним, помогает ли очистка кэша:

1. Удалим базу из списка запуска 1С и добавим её заново (это очистит идентификаторы кэша).
2. Или вручную очистим папки %AppData%\Local\1C\1Cv8 и %AppData%\Roaming\1C\1Cv8.

Шаг 7. Специализированные отчеты по правам

Для детального сравнения рекомендуется использовать встроенные или внешние отчеты. В современных версиях это отчет «Права доступа» в карточке пользователя. Для старых конфигураций (УТ 10.3) можно воспользоваться консолью запросов или внешними обработками типа «Анализ прав доступа 2.0».

С помощью таких инструментов мы можем увидеть сводную таблицу по всем ролям и объектам, что позволит быстро заметить, какая именно роль дает право на Изменение и почему она может не срабатывать у конкретного сотрудника.

Подведем итог: если роли одинаковые, а права разные, ищите причину в регистре дополнительных прав, настройках RLS (группах доступа), дате запрета или в программных проверках внутри модулей 1С. Как показал пример из практики, даже банальная опечатка в дате в коде модуля может привести к блокировке работы конкретного пользователя.