В помощь администратору: простая подсистема отправки текстовых предупреждений (для обычного приложения)

Коротко о возможностях. Все просто, грубо, а самое главное, действенно.

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

Типы предупреждений.

1. Простое предупреждение. Появляется на экране пользователя, на кнопке «Отмена» тикает таймер. Если пользователь проигнорировал или нажал отмену, через заданный интервал сообщение появляется снова. До нажатия «ОК».

Пример. Предупредить можно о чем угодно. Например о предстоящем перезапуске или об изменениях конфигурации.

2. Предупреждение о перезапуске. Появляется на экране пользователя, на кнопке «Отмена» тикает таймер. Появляется через заданный интервал до тех пор, пока пользователь не перезапустит сеанс.

Или, если пользователь нажмет «ОК», ему будет задан вопрос, действительно ли он хочет перезапуститься прямо сейчас. В случае положительного ответа система перезапускается, в случае отрицательного — через заданный интервал сообщение появится снова.

Пример.  Внесены изменения в дополнительные права пользователя, или назначена новая роль и т.п.

3. Жесткий перезапуск. Появляется на экране пользователя, на единственной кнопке «ОК» тикает таймер. Когда таймер дотикает, система будет перезапущена. Если пользователь нажмет «ОК», система перезапустится сразу после нажатия.

Пример. Для тех, кто не внял просьбе в п. 2 и это создает различные неудобства в работе.

4. Жесткое выключение. То же, что и в п.3, только система перезапущена не будет. Если пользователь захочет, то сможет вернуться в программу.

Пример. Сложно сказать… Но как возможность оставил.

5. Жесткое выключение с блокировкой. Почти то же, что и в п.3. Но… (см.ниже)

Но при входе в программу на заданное время будет показано предупреждение о том, что система недоступна и программа закроется.

 

Пример. Звонит бухгалтерия, говорит, что после последнего внесения изменений перестал работать клиент-банк, а надо срочно отправлять платежи. В базе больше сотни пользователей. Хотя и сам лопух, что накосячил, но надо что-то делать. Вариант действий. 1. Отправляем всем сообщение №5 («жесткое выключение с блокировкой»). Наблюдаем через список активных пользователей как пользователи «покидают» программу. Оставшихся «в живых» (те, у которых были открыты модальные окна, ушли пить чай и заблокировали систему или просто висят) выключаем через терминальное подключение. 2. Обновляем программу с исправлением косяков, очищаем сообщения с блокировкой, отзваниваемся об успешно проделанной работе.

P.S. Для полноты контроля можно использовать конфигурацию-прокладку (//infostart.ru/public/325051/). Тогда предварительно с её помощью блокируем вход в базу для новых пользователей до окна входа в основную базу. После выполнения шагов 1-2 (из примера к предупреждению №5) возвращаем прокладку в исходное состояние.

P.S.S. Дочитавшим досюда. Еще пара фишек. 1. У простого сообщения (п.1) можно поставить флаг «Не удалять». Тогда при нажатии пользователем кнопки «ОК» или «Отмена» в списке сообщений можно увидеть проставленный флаг «Сообщение прочитано». Может и  не прочитали, но как-то прореагировали. 2. Сообщение о перезапуске, не жестком, также помечается прочитанным в случае нажатия «ОК» или «Отмена», дополнительных флагов для этого взводить не нужно. Т.е. пользователь прочитал. но все-таки не перезапустился. Тогда можно ему послать предупреждение типа 3 (жесткий перезапуск) или, из «вредности», типа 4 (жесткое выключение).

Для тех, кого заинтересовало, далее техническая информация.

Подсистема полностью готова к работе и предназначена для к объединению с конфигурацей на обычном приложении, в составе которой есть справочник «Пользователи» и параметр сеанса «ТекущийПользователь».

Конфигурация содержит: собственно подсистему, 1 общий модуль, 2 роли (админ и пользователь), 1 форму констант, 4 константы, 1 простейший интерфейс, 1 справочник (шаблоны сообщений), 1 обработку и 1 регистр сведений. Все объекты имеют префикс «ДМ_СП».

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

Далее надо дать пользователю-администратору роль «ДМ_СП_Администратор», остальным, кому предполагается отправлять сообщения дать другую роль, «ДМ_СП_Пользователь».

Для удобства желательно добавить интерфейс в список интерфейсов.

В модуль обычного приложения в самое начало процедуры ПриНачалеРаботыСистемы() добавляем строку:

ДМ_СП_ПриНачалеРаботыСистемы();

Туда же, но в конец процедуры ПриЗавершенииРаботыСистемы() добавляем строку:

ДМ_СП_ПриЗавершенииРаботыСистемы();

При первом запуске заходим в форму констант.

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

После установки флажка использования подсистемы, каждому новому входящему пользователю будет подключен обработчик ожидания, срабатывающий через интервал, указанный в константе «Интервал показа сообщения».

Обработка отправки сообщений формирует два списка отправки: активных пользователей (для использования этой возможности необходимо точное соответствие имени пользователя БД и имени пользователя в справочнике) и всех пользователей.

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

Обработка интуитивно понятна и проста. Пожелания приветствуются. В скором времени будет готов и добавлен вариант подсистемы для управляемых форм (также за стартмани).

Похожие идеи (не заимствовал, пришел параллельно):

//infostart.ru/public/126247/

//infostart.ru/public/334073/

Дополнительная поддержка разработчика: WMR R370288533796