Как разрешить редактирование штатного расписания в ЗУП 3.1 без права проведения?

Программист 1С v8.3 (Управляемые формы) Управленческий учет IT и автоматизация бизнеса
← На главную

В типовой конфигурации 1С:Зарплата и управление персоналом 3.1 часто возникает задача разделить полномочия сотрудников. Например, один специалист должен иметь возможность создавать и редактировать документы Изменение штатного расписания или Утверждение штатного расписания, а другой — проверять их и окончательно проводить. Однако стандартная настройка ролей в конфигураторе не всегда работает так, как ожидается: при снятии права на Проведение форма документа в пользовательском режиме часто становится доступной только для чтения.

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

Анализ проблемы: почему стандартные роли не справляются?

Проанализируем поведение системы. В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем), к которым относится и ЗУП 3.1, интерфейс форм управляется динамически. Когда пользователь открывает документ, срабатывает процедура ПриСозданииНаСервере. В этой процедуре система проверяет наличие прав доступа. Если логика конфигурации определяет, что у пользователя нет права на проведение документа, она зачастую устанавливает свойство формы ТолькоПросмотр = Истина.

Логика разработчиков типового решения проста: если вы не можете провести документ, то и редактировать его «черновик» вам незачем. Но в реальных бизнес-процессах это не так. Попытка создать новую роль в расширении и просто снять галочки «Проведение» и «Отмена проведения» приводит к тому, что кнопка «Записать» исчезает, а поля блокируются.

Выясним причину глубже: помимо самих прав на документы, существуют права на регистры сведений, в которые эти документы делают записи (например, ИсторияИзмененияШтатногоРасписания). Также важную роль играют шаблоны RLS (Ограничение прав на уровне записей). Если вы копируете роль, но не учитываете все связанные объекты, система ограничивает доступ до минимально безопасного — «Только чтение».

Решение проблемы через программный код в расширении

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

Разберем по шагам, как это реализовать:

  1. Создадим новое расширение (или используем существующее).
  2. Добавим в расширение документы ИзменениеШтатногоРасписания и УтверждениеШтатногоРасписания.
  3. Для каждого из этих документов создадим обработчик события ПередЗаписью в модуле объекта (через метод &После или &Перед).
  4. Добавим в расширение новую роль, назовем ее, например, ЗапретПроведенияШтатногоРасписания. Эта роль не будет иметь никаких прав в метаданных, она будет служить «маркером» для нашего кода.

Посмотрим на пример кода, который необходимо разместить в модуле объекта документа в расширении:


&Перед("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    
    // Проверяем, что документ пытаются именно провести
    Если РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
        
        // Проверяем наличие нашей специальной роли-маркера у текущего пользователя
        Если РольДоступна("ЗапретПроведенияШтатногоРасписания") Тогда
            Отказ = Истина;
            Сообщение = Новый СообщениеПользователю;
            Сообщение.Текст = "У вас недостаточно прав для проведения этого документа. Вы можете только сохранить его как черновик.";
            Сообщение.Сообщить();
        КонецЕсли;
        
    КонецЕсли;
    
КонецПроцедуры

Преимущества использования роли-маркера

Проанализируем, почему использование конструкции РольДоступна в коде удобнее, чем жесткая привязка к именам пользователей или конкретным группам доступа:

Нюансы работы с БСП и обновлением данных

При добавлении новых ролей через расширение в ЗУП 3.1 важно помнить о механизмах справочника Идентификаторы объектов метаданных. Если вы добавили роль, назначили ее пользователю, но код не срабатывает или роль «не видится» в профилях групп доступа, необходимо выполнить обновление вспомогательных данных.

Рассмотрим, как это сделать:

Запустите базу с параметром командной строки: /С ЗапуститьОбновлениеИнформационнойБазы. Это заставит систему пересчитать все идентификаторы объектов, включая те, что находятся в расширениях. После этого ваша роль корректно появится в списке доступных ролей для создания профилей групп доступа.

Рекомендации для версии ЗУП КОРП

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

Однако для версии ПРОФ описанный выше метод с программным прерыванием в ПередЗаписью является наиболее стабильным и рекомендуемым к внедрению.

Итоги

Мы проанализировали ситуацию, когда типовые средства настройки прав доступа в 1С:ЗУП 3.1 не позволяют гибко разделить запись и проведение документов штатного расписания. Использование расширения с перехватом события ПередЗаписью и проверкой роли-маркера позволяет решить эту задачу эффективно и без нарушения логики работы типовых экранных форм.

← На главную