Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток Вопрос в следующем: Необходимо послать сформированное уведомление N пользователям. Уведомление информативное, т.е. из действий только кнопка Ок. В принципе уведомления рассылаются Но проблема в том что начиная со второго пользователя уведомления получают статус на Open, а Cancel... Какие могут быть мысли? Уточнение: Модификация процесса Утверждения ЗП, для рассылки уведомлений об "Отмене" ЗП, всем пользователям по иерархии. Так вот стандартно, составитель ЗП получает нормальное уведомление, а все остальные в статусе Cancel Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 21:25 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
Ну это в настройках надо смотреть цепочки утверждения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 22:08 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
Нет Это не стандартные цепочки утверждений Это своя доработка WorkFlow который работает при утверждении. Вот на выходе, при статусе "Отмена" встраиваешься, так уведомления отсылаются в статусе "Отмена" - а надо "Открыто" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 23:27 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
Info2Модификация процесса Утверждения ЗП, для рассылки уведомлений об "Отмене" ЗП, всем пользователям по иерархии. Так вот стандартно, составитель ЗП получает нормальное уведомление, а все остальные в статусе CancelКак именно сделана модификация - вот что важно. Схемку бы посмотреть и кастомизированные процедуры к ней. Я бы навскидку не знаю, как сделал бы, но факт: не стал бы все отправлять из одной activity в один этап. Если бы использовал одну activity, то замкнул бы ее в цикл, с помощью скорее всего какого-нибудь дополнительного атрибута (например, туда можно писать получателя уведомления). Тут еще важно, как эта notification определена в workflow - надо, чтобы поток понимал, что при новом попадании на узел вся работа велась бы как в первый раз. Самое простое - вместо одного уведомления цепочку одинаковых уведомлений (достаточное количество, чтоб туда максимально длинная ветвь иерархии помещалась), базирующихся на одном message, но для всех разного получателя задавать. Лишние - отключать (условные activities между уведомлениями). Совсем экзотично - создавать временную или постоянную роль в directory services, а в ней адреса электронной почты прописать через запятую. Но этот способ - только при использовании электронной почты, так как собственно в сводку уведомлений к утверждавшим ничего не упадет (роль-то ненастоящая) - а вот письмо каждый получит. А вопрос можно? Зачем понадобилось так много уведомлений об отклонении? Только инициатора утверждения ставить в известность - не достаточно ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 23:41 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
В том то и дело, что одного составителя документа уведомить мало. Захотелось пользователям, чтобы все кто утверждал (промежуточное начальство) тоже получало уведомление, если самый высокий начальник отклонил ЗП. Да так и сделано... В POAPPRV в конце, если выход по событию "Отклонено" то работает еще цикл, скопированный как для стандартной "Отклонено" цикл работает уведомления идут но статус их уже "Cancel" - пользователи их не видят в открытых уведомлениях Только если смотреть все уведомления видно. Чтото предложение не понятно... Работает: просматривает историю утверждения вниз, и всех по ней уведомляет, что было отклонение.... Но одна беда - что выше, остается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 11:02 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
А те, кто выше - формально еще ничего не утверждали ;-) Кстати, а в случае делегирования полномочий вы как поступаете? Ведь реально утверждал заместитель, а в истории утверждения этого не видно, т.е. уведомление об отклонении пойдет утверждающему из иерархии? Нет, про статус уведомлений навскидку не смогу ничего сказать - копаться надо. И даже, возможно, глубоко. Но могу предложить рассмотреть следующее предположение. Вот отсылается первое уведомление первому получателю, потом по циклу возвращаемся на этот же шаг и что система может подумать? Ага, прошлое уведомление снимаем (переводим в canceled), а вместо него отправляем другое (следующему утверждающему). Такое может быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 01:45 |
|
||
|
Отсылка уведомления с помощью WorkFlow в OEBS
|
|||
|---|---|---|---|
|
#18+
Уже работает: 1. В цикле уведомления отсылать нельзя, так как когда цикл повторно заходит на точку, где отсылалось уведомление - то предыдущие уведомления, отосланные с этой точки - принудительно переводятся в "Canceled". Хоть и разные получатели. А жаль... 2. Решение1 - статически рисуется WorkFlow цепочка на отсылку не больше 10 уведомлений, с условием перед каждой отсылкой - отправляем или нет. Минус - фиксированное число уведомлений. 3. Решение2 - на лету создается AdHocRole с уникальным именем, формируется и к ней цепляется список пользователей кому надо отослать уведомление. Дальше стандартно, шлется уведомление на эту роль. Минус: атрибут "Кому" является фиксированным для всех получателей, и равняется имени роли.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 18:50 |
|
||
|
|

start [/forum/topic.php?fid=29&fpage=59&tid=1528003]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
30ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 329ms |

| 0 / 0 |
