Pull to refresh

Comments 3

Спасибо за статью, почти также делаем. Модель действительно усложняется, когда нужно учитывать:
— способ уведомлений (sms, push, email и пр.)
— совпадение ролей (например, инициатор и утверждающий)
— прочие условия (например, если сумма превышает определенный лимит, то дополнительно уведомить кого-то)
— необходимость уведомлений, когда в системе Пользователь не выполняет никаких событий (например, рассылка напоминаний)

Отдельно выделяем блок комплексных уведомлений. Например, раз в день отправлять сборный список задач.
А как же — делегирование?) Генеральный поставил задачу начальнику отдела — начальник отдела — начальнику группы — начальник группы — 3-4 подчиненным) и понеслось…
А эти подчиненные — не видели, не слышали, забЫ(и)ли… Тоже приходится дублировать, менять способ оповещения, иногда даже — прибегать к автоматической постановке задачи на контролирующего…
При делегировании обычно подпроцесс со своими ролями: Инициатор-Исполнитель. В данном случае дерево подпроцессов. И для нее прописываем логику уведомлений по тому же принципу.

Но уведомления тут тоже, конечно, можно навертеть — жестко логику зашивать или запрашивать еще у пользователя.

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

Вобщем-то всегда может быть много условий, от чего зависит матрица. Скорее всего она будет не двумерной.
Sign up to leave a comment.