Notify users
Надо продумать механизм оповещения пользователей. Идея простая - есть пользователи, мы нашли критический баг, надо чтобы все перезашли. Выкидывать всех - опасно. Поэтому предлагаю сделать некий механизм, который будет работать приблизительно так:
- Я создаю некий документ, где я указываю сообщение на разных языках (могу и на одном), указываю пользователей, указываю дату сообщения, количество повторов, ожидаю ли действий от пользователя. Данные попадают в регистр сведений.
- Указываю пользователей по таким вариантам:
- Все пользователи, которые активны на текущий момент (т.е. я обновил расширение, и мне надо уведомить всех, кто сейчас в базе, мне не надо уведомлять больше никого, если человек зашел в базу позже, ему не должно показаться уведомление)
- Все пользователи, в независимости от того в базе они или нет
- Выбрать список пользователей или их группу, и послать уведомление только им
- Указываю действия:
- Просто оповестить, ничего не делать. У пользователя просто появляется сообщение и кнопка ОК. В регистре фиксируется инфа о том, когда сообщение отобразилось и когда пользователь ткнул на ОК.
- Оповестить о том, что надо перезайти в программу. Тут мы делаем кнопки "Сейчас", "Позже". Указываем количество повторов. Если мы указали 3, то тогда только 3 раза пользователь может отложить, после этого у него будет только кнопка "Сейчас" доступна. И при нажатии на нее - программа попробует закрыться (если у него есть не сохраненные данные, то система их предложит сохранить). Если стоит 0, то тогда он может бесконечно это делать. Промежуток между оповещениями - 1 минута.
- Ответ от пользователя. С вариантами ответа. Например, я опрашиваю магазины - есть у вас сканер, или подвисает ли программа, или там открывается фото или нет. И даю список вариантов ответов. Как пользователь отвечает - данные попадают в регистр. Варианты опять таки на нескольких языках.
- Указываю время, когда у них отобразится сообщение. Варианта три:
- фиксированное время по локальному времени пользователя
- по локальному времени сервера
- указать через сколько минут. Типо через 5 минут от даты создания оповещения
Так же указать надо шедулер, типо повторять кадый день - в такое то время (сбрось мне отчеты по кассе)
Предлагаю не смешивать сообщения и каналы их доставки - выполнять их независимую разработку.
Каналы. Не все "потребители" информации работают в IRP, а те, кто работают, могут заходить туда крайне редко, посмотреть информацию. Следовательно информация должна доставляться не только уведомлениями в системе, но и альтернативными путями - письмами, сообщениями в телеграмм-бот и так далее. При чем будет отлично, если у пользователей будет возможность настраивать удобные для них каналы доставки сообщений.
Типы сообщений. Думаю, что сперва нужно провести классификацию видов сообщений, так как у них уникальное поведение.
- Очевидно, что для уведомлений про технические работы на серверах нужно отправлять уведомления заранее, при чем для разных должностей зазор может различаться. И тут полезна опция запросить задержку такого обновления, если это возможно.
- Экстренные уведомления - для них важно доставить быстро к адресатам и быстро получить ответную реакцию (как выше вопрос про неработающий сканер).
- Для опросов срочность не важна, но может быть важной дата завершения опроса и формирование отчета по результатам опроса (например собирают мнения об установке в офисе безлимитного кофейного автомата, за пользование которым будут делать небольшие удержания из зарплаты).
- Контекстные уведомления, когда вопрос и ответ задаются в рамках конкретного документа или справочника (запрос даты готовности у цеха по продукции, которую уже нужно отгрузить конкретному клиенту).
- Сообщения в рамках бизнес-процессов (визирование заявок, тендеры, кадровые процессы)
Если выбирать образцы для изучения и "вдохновения", то из известных мне существующих решений наиболее понравилась реализация в 1С:Документообороте. Хоть там слишком "многословно" и "громоздко", но возможности впечатляют.
Для обычного общения людей - можно применить системы вщаимодействий. Которая уже интегрирована со всем чем надо. Включая и внешних пользователей.
Тут больше речь про системные уведомления и класификацию ответов. Т.е. этой системой будут пользоваться тоьько внедренцы, грубо говоря. А то о чем пишешь ты - это уже больше срм и внутреннее взаимодействие
@DitriXNew может тут лучше задействовать Tasks? Фиксация и хранение факта и истории получения/изменения уведомления тоже иногда бывает важна.