В процессе работы с конфигурацией 1С:Документооборот (особенно в версии 2.1) многие администраторы сталкиваются с проблемой «информационного шума» при делегировании прав. Типичная ситуация: права сотрудника А делегируются сотруднику Б, и на следующее утро сотрудник Б получает десятки, а иногда и сотни писем о том, что задачи, где сотрудник А является автором, просрочены. Это происходит из-за того, что система по умолчанию старается максимально полно информировать заместителя о состоянии дел подопечного.
В этой статье мы подробно разберем, почему так происходит, и проанализируем несколько способов решения проблемы: от простых административных настроек до внесения изменений в программный код.
Прежде всего, выясним причину. В 1С:ДО за отправку писем отвечает регламентное задание УведомлениеПользователейОСобытиях. Оно анализирует записи в регистре сведений ОчередьУведомлений. Когда мы настраиваем делегирование прав, система начинает сопоставлять права и подписки сотрудника А с учетной записью сотрудника Б.
Если у сотрудника А в персональных настройках включено уведомление «Просрочена задача автора», то система считает, что его заместитель (сотрудник Б) также должен получать эти оповещения. Ситуация осложняется тем, что при активации делегирования система может «поднять» старые записи о просрочках, которые накопились в очереди, и отправить их все разом в момент старта регламентного задания (обычно это происходит в начале рабочего дня, например, в 8:00).
Первым делом проанализируем глобальную настройку делегирования. Рассмотрим шаги для проверки:
Если этот флажок установлен, Сотрудник 2 будет получать абсолютно все уведомления, предназначенные для Сотрудника 1. Важный нюанс: отключение этого флажка решит проблему с «авторскими» просрочками, но при этом Сотрудник 2 перестанет получать и полезные уведомления (например, о новых задачах, поступивших Сотруднику 1). Если ваша цель — полностью разделить потоки уведомлений, этот метод подходит лучше всего.
Посмотрим на ситуацию со стороны Сотрудника 1 (чей функционал делегируется). Уведомление «Просрочена задача автора» срабатывает тогда, когда исполнитель не выполнил задачу в срок, а автор (Сотрудник 1) подписан на это событие.
Рассмотрим порядок действий:
После этого система перестанет генерировать события данного типа для этого пользователя, а значит, они не попадут и к его заместителю. Это наиболее безболезненный способ, если автору самому не критично отслеживать просрочки в реальном времени через почту (он может увидеть их в интерфейсе программы в списке «Мои процессы»). Для отслеживания таких срывов сроков без почтовой рассылки можно использовать отчет с диаграммой по задачам исполнителей с нарушением сроков.
Если делегирование уже включено и Сотрудник 2 уже начал получать письма, нам нужно остановить этот поток. Выясним, как это сделать технически. Все готовые к отправке письма хранятся в регистре ОчередьУведомлений.
Для предотвращения «утреннего спама» администратор может:
ОчередьУведомлений.Также полезно проверить настройку «Срок хранения уведомлений» в общих настройках программы. Если установить там разумный предел (например, 3-5 дней), система не будет пытаться отправить уведомления годичной давности, которые могли стать актуальными для заместителя в момент получения прав.
Если типовые настройки не позволяют добиться нужного поведения (например, нужно получать уведомления о новых задачах, но игнорировать просрочки автора), проанализируем возможность доработки кода. Основная логика формирования уведомлений сосредоточена в общем модуле УведомленияПользователей.
Мы можем внести изменения в процедуру, которая определяет список получателей. Рассмотрим пример логики, которую можно внедрить:
// В общем модуле УведомленияПользователей находим место формирования списка получателей
// Проверяем, является ли текущее событие просрочкой задачи автора
Если Событие = Справочники.СобытияУведомлений.ПросроченаЗадачаАвтора Тогда
// Если получатель — не сам автор, а заместитель по делегированию, исключаем его
Если Получатель <> Объект.АвторЗадачи Тогда
Продолжить; // Пропускаем отправку данному получателю
КонецЕсли;
КонецЕсли;
Такая доработка позволит сохранить уведомления для непосредственного автора (если он вернется из отпуска и захочет увидеть просрочки), но оградит его заместителя от лишней информации.
В более поздних редакциях 1С:ДО 2.1 функционал справочника События уведомлений стал шире. Разберем шаги по тонкой настройке:
Подводя итог, проанализируем наиболее эффективную стратегию:
Если проблема носит разовый характер, проще всего очистить очередь уведомлений и отключить флажок пересылки в правилах делегирования. Если же компания активно использует механизм авторского контроля и делегирование происходит часто, рекомендуется выполнить небольшую программную доработку модуля УведомленияПользователей, чтобы система на уровне ядра разделяла «личные» задачи исполнителя и «авторские» задачи того, кого он замещает.
Также стоит рассмотреть переход на 1С:Документооборот 3.0, где механизмы работы «Замещающих» и «Помощников» разделены более четко, что позволяет гибко настраивать права на получение почты без вмешательства в программный код.