Настройка прав в УТ 10.3: почему у нового администратора ограничено редактирование документов и цен?

← На главную

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

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

---

Шаг 1. Проверка индивидуальных настроек даты запрета изменения данных

Первое, на что необходимо обратить внимание — это механизм даты запрета редактирования. Даже если у пользователя установлена роль Полные права, система может блокировать изменения, если включена соответствующая опция контроля.

Выясним, как настроена эта подсистема в вашей базе:

Перейдем в меню Сервис — Настройка учета — Установка даты запрета изменения данных.
В открывшемся окне обратим внимание на вкладки. Настройка может быть общей для всех пользователей, а может быть детализирована по конкретным сотрудникам или организациям.
Проверим вкладку Пользователи. Если там перечислены конкретные пользователи, велика вероятность, что для старого администратора было сделано персональное исключение (например, для него дата запрета не установлена или сдвинута далеко в прошлое). Новый администратор автоматически в этот список исключений не попадает, поэтому система применяет к нему общие, более строгие правила.
Добавим нового администратора в этот список и настроим для него аналогичные права доступа.

Также проверим глобальную настройку применения даты запрета для администраторов. Для этого перейдем в меню Сервис — Настройка учета — Настройка параметров учета. На вкладке Общие проверим, установлена ли галочка «Применять дату запрета редактирования для полных прав». Если она включена, то даже полные права будут ограничиваться установленными датами запрета.

---

Шаг 2. Анализ персональных настроек пользователя

При обычном копировании элемента в справочнике Пользователи или создании учетной записи в Конфигураторе персональные настройки пользователя, хранящиеся в регистре сведений Настройки пользователей, автоматически не переносятся. Их необходимо скопировать вручную.

Выполним следующие действия под учетной записью старого администратора:

Откроем меню Сервис — Настройки пользователя.
Внимательно изучим установленные флаги. Здесь находятся критически важные параметры контроля, такие как «Отражать в управленческом учете», «Отражать в бухгалтерском учете», настройки контроля остатков и специфическое поведение при редактировании цен.
Для переноса настроек нажмем кнопку «Копировать настройки» (или «Скопировать другому пользователю») на панели формы и выберем в качестве получателя нашего нового администратора. Это гарантирует полную идентичность персонального окружения.

---

Шаг 3. Сопоставление пользователя ИБ и элемента справочника «Пользователи»

Распространенная ошибка при ручном заведении административных аккаунтов — рассинхронизация учетной записи в Конфигураторе и элемента справочника Пользователи в режиме Предприятия.

В системе 1С при запуске сеанса инициализируется важнейший параметр ПараметрыСеанса.ТекущийПользователь. Если связь между пользователем информационной базы (созданным в Конфигураторе) и элементом справочника нарушена:

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

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

---

Шаг 4. Настройка групп пользователей и RLS (Доступ на уровне записей)

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

Проанализируем эти настройки по шагам:

Перейдем в меню Сервис — Пользователи — Группы пользователей.
Найдем группы, в которые включен старый администратор.
Добавим нового администратора в те же самые группы.
Перейдем в меню Сервис — Администрирование пользователей — Доступ на уровне записей и убедимся, что для групп, в которых состоит новый пользователь, настроены соответствующие виды доступа (по организациям, контрагентам, складам и т.д.).
Важно: После добавления пользователя в группы обязательно перезапустим сеанс работы с базой данных, чтобы кэш прав обновился.

---

Шаг 5. Поиск скрытых доработок в коде (Hardcode)

Поскольку конфигурация не является полностью типовой, существует высокая вероятность того, что предыдущие программисты внедрили ограничения непосредственно в программный код системы под конкретную учетную запись. Это так называемый «хардкод» (hardcode), когда логика завязывается на конкретное имя пользователя или его уникальный идентификатор (GUID).

Проанализируем программный код конфигурации. Для этого откроем базу в режиме Конфигуратор и выполним глобальный поиск (сочетание клавиш Ctrl + Shift + F):

В строке поиска укажем точное наименование (в кавычках) старого администратора, например: "Администратор" или "ИвановИИ".
Область поиска установим во всей конфигурации.

Особое внимание обратим на следующие участки кода:

Модуль обычного приложения: процедура ПриНачалеРаботыСистемы. Здесь могут переопределяться параметры сеанса или принудительно устанавливаться даты запрета редактирования.
Общий модуль ПолныеПрава: процедура УстановитьПараметрГраницыЗапретаИзмененияДанных. Разработчики часто встраивают туда обход ограничений для конкретных имен учетных записей. Пример такой конструкции, которую мы можем встретить:


Если глЗначениеПеременной("глТекущийПользователь").Наименование = "Администратор" Тогда
    // Игнорируем дату запрета для главного администратора
    Возврат;
КонецЕсли;

Подписки на события: Проверим обработчики событий ПередЗаписью для документов или справочника ЦеныНоменклатуры. В них может содержаться логика блокировки изменения реквизитов (например, цен или дат документов) для всех пользователей, кроме конкретно указанного в коде.

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