← На главную

Стандартный механизм делегирования в 1С:Документооборот позволяет передать все полномочия в рамках определенной области, например, "Процессы и задачи". Однако часто возникает бизнес-потребность в более гибкой настройке: один тип задач делегировать одному заместителю, другой — второму, а некоторые, особо конфиденциальные (например, согласование авансового отчета руководителя), не делегировать вовсе. Типовыми средствами решить такую задачу невозможно, поэтому рассмотрим несколько подходов к доработке системы.

Проанализируем ситуацию: руководитель хочет, чтобы его рабочие задачи по договорам видел заместитель А, а задачи по служебным запискам — заместитель Б. При этом задачу по своему авансовому отчету не должен видеть никто из них. Стандартное делегирование области "Процессы и задачи" передаст все три задачи и заместителю А, и заместителю Б, что недопустимо.

Рассмотрим несколько рабочих сценариев доработки конфигурации для реализации выборочного делегирования.

Решение 1: Расширение стандартных областей делегирования

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

Разберем по шагам:

1. Добавление новых областей. В конфигураторе необходимо расширить перечисление ОбластиДелегированияПрав и добавить в него новые предопределенные значения. Например:

   • ПроцессыПоДоговорам
   • ПроцессыПоСлужебнымЗапискам
   • ФинансовыеПроцессы

   После этого пользователи в интерфейсе настройки делегирования увидят эти новые области и смогут настраивать передачу прав по ним раздельно.

2. Адаптация механизма создания задач. Это самая сложная часть. Система должна понимать, к какой из наших новых областей относится каждая создаваемая задача. Для этого потребуется доработать логику в общих модулях, отвечающих за старт процессов и создание задач (например, УправлениеБизнесПроцессами, РаботаСЗадачами).

   Логика определения области может быть основана на различных атрибутах:

   • Вид документа, который является предметом задачи (например, если вид документа "Договор", задача относится к области ПроцессыПоДоговорам).
   • Шаблон бизнес-процесса, по которому запущена задача.
   • Наличие определенного реквизита в предмете задачи.

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

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

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

Недостатки: Требует значительного вмешательства в типовую логику маршрутизации и расчета прав, что может усложнить последующие обновления конфигурации.

Решение 2: Программная фильтрация и блокировка задач

Этот метод предлагает не изменять механизм делегирования, а "исправлять" его результат на лету. Руководитель делегирует все процессы и задачи типовым способом, а наша доработка будет отсекать лишнее, не давая заместителям видеть ненужные задачи.

Рассмотрим подробнее:

Создается специальный регистр сведений, например, ПравилаБлокировкиДелегированныхЗадач, где будут храниться правила фильтрации. Структура регистра может быть следующей:

• Сотрудник (для кого настроено правило)
• Заместитель (кому запрещается видеть задачу)
• КритерийФильтрации (перечисление: ВидДокумента, ШаблонПроцесса и т.д.)
• ЗначениеКритерия (ссылка на конкретный вид документа, шаблон и т.п.)

Далее реализуем саму логику блокировки через подписку на событие.

1. Создаем подписку на событие. Нам нужна подписка на событие ПередЗаписью объекта ЗадачаИсполнителя.

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

   Скопировать код

   
   // Примерный код обработчика в общем модуле
   Процедура ЗаблокироватьЛишниеДелегированныеЗадачи(Источник, Отказ) Экспорт
       
       // Проверяем, что это новая задача и у нее есть исполнитель
       Если Источник.ЭтоНовый() И ЗначениеЗаполнено(Источник.Исполнитель) Тогда
           
           // Получаем список тех, кто делегировал права текущему исполнителю
           ДелегировавшиеПользователи = ПолучитьДелегировавшихПользователей(Источник.Исполнитель);
           
           Если ДелегировавшиеПользователи.Количество() > 0 Тогда
               // Задача пришла по делегированию. Нужно проверить, не запрещена ли она.
               Для каждого Делегат Из ДелегировавшиеПользователи Цикл
                   
                   // Проверяем наличие правила блокировки в нашем регистре
                   Если ЕстьПравилоБлокировки(Делегат.Пользователь, Источник.Исполнитель, Источник.Предмет) Тогда
                       
                       // Если правило найдено - не даем создать задачу
                       Отказ = Истина;
                       
                       // Можно также выдать сообщение пользователю или записать в журнал
                       Сообщить("Создание делегированной задачи заблокировано согласно настроенным правилам.");
                       
                       Возврат;
                   КонецЕсли;
                   
               КонецЦикла;
           КонецЕсли;
           
       КонецЕсли;
       
   КонецПроцедуры
   

Важный момент: Вместо полного отказа в записи (Отказ = Истина) можно реализовать и другие сценарии. Например, не блокировать создание задачи, а очистить поле Исполнитель или реализовать автоматическое перенаправление задач другому сотруднику. Однако самый надежный способ скрыть задачу — это не дать ей записаться для данного исполнителя.

Преимущества: Метод менее инвазивен по отношению к ядру механизма делегирования и маршрутизации. Его легче реализовать через расширение конфигурации.

Недостатки: Может создавать "невидимые" сбои в бизнес-процессах, если задача просто не создается, а процесс ждет ее выполнения. Требуется тщательная проработка логики и оповещений.

Решение 3: Управление доступом через рабочие группы документов

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

Посмотрим на пример с авансовым отчетом:

1. Стандартное делегирование. Руководитель, как и раньше, настраивает полное делегирование области "Процессы и задачи" своему заместителю.

2. Автоматизация рабочей группы. Мы дорабатываем шаблон бизнес-процесса "Согласование авансового отчета". В самом начале процесса (например, на шаге "Старт") добавляем действие "Обработка" с небольшим скриптом.

3. Скрипт управления доступом. Этот скрипт должен принудительно изменить рабочую группу документа (авансового отчета), который является предметом процесса. Для подобных манипуляций в административных целях также существуют готовые инструменты, позволяющие выполнять групповую очистку рабочей группы по заданным критериям.

   Скопировать код

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

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

Преимущества: Минимальное вмешательство в код. Вся логика настраивается на уровне шаблонов процессов. Это самый безопасный способ с точки зрения обновлений.

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

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