Добрый день!
itil 7.6
Подскажите, пожалуйста,почему может не работать счетчик уведомлений для уведомлений, связанных с объектом "изменение"
( причем с объектом "обращение" счетчик работает)
Выглядит это так
- на иконке кол-во не отображается, но уведомления есть

Сверяли уведомления в таблице Reminding - заполнены корректно

Нравится

10 комментариев

Здравствуйте, Дарья!

А подключение по websocket есть?

Добрый день!
А где это проверить необходимо?

Здравствуйте!

Давайте по другому - у Вас работают процессы (элементы взаимодействия с пользователем открываются)?

Алексей, все процессы работают)
более того, уведомления по обращениям, например, отображаются в этом счетчике.
А вот уведомления по изменениям почему-то в этом счетчике не считаются - на иконке уведомлений в панельке счетчик не реагирует на существование этих изменений

Здравствуйте, Дарья!

За обновление количества уведомлений отвечает процесс "Получить количество уведомлений". Он журналируется. Проверьте, пожалуйста, он завершается с ошибкой или нет.

Также, уточните следующие параметры:
1) Часовой пояс на локальной машине пользователя
2) Часовой пояс в профиле пользователя
3) Часовой пояс на сервере, где развернуто приложение.

Добрый день, Алексей!
Процесс "Получить кол-во уведомлений" с ошибкой НЕ завершается.
С часовыми поясами тоже все в порядке.
Дело не в конкретном пользователе

Проверяем как на облачной базе, так и на базе он-сайт тестовой.
Смотрите, какая ситуация:
Вообще счетчик уведомлений работает, но он работает только, если уведомление связано с объектом "Обращение"- только их он считает.
Если же уведомление связано с объектом "Проблема" или "Изменение" - то счетчик Не считает такие уведомления, он их не учитывает,хотя они есть - их можно посмотреть.

Есть три аналогичных процесса.
1. Создает уведомление по обращению - такое уведомление попадает в счетчик
2.Создает уведомление по проблеме - такое уведомление НЕ попадает в счетчик
3.Создает уведомление по изменению - такое уведомление НЕ попадает в счетчик

Для каждого раздела есть свой провайдер, который считает количество уведомлений. Для этих разделов его скорее всего нет, т.к у проблемы и изменения нет состояния. Предполагаю, что дело именно в этом.
Попробуйте решить эту задачу, создавая техническую активность элементом "Открыть страницу редактирования". Ссылка будет создаваться на активность и счетчик будет реагировать на нее.

У проблемы и изменения есть " состояние ", так что непонятно отсутствие провайдера.
Если у каждого раздела есть свой провайдер, который считает кол-во уведомлений,то не очень понятно почему же забыли создать такие провайдеры для разделов "Проблемы", "Изменения", "Релизы" и т.д.

Создавать техническую активность вообще не выход,это приведет к захламлению системы ненужными активностями, да и уведомление должна создаваться к объекту, а не к активности.

Как тогда включить необходимый провайдер?
В счетчике должны отображаться уведомления по всем объектам, к которым можно создать уведомления - по крайней мере к основным разделам системы уж точно.
Алексей, ну он должен быть заложен в систему.
То, что уведомления создаются, но не считаются в счетчике - это же ошибка(
Причем сами эти уведомления отражаются в панели уведомлений справа

создали UsrProblemNotificationProvider
по аналогии с CaseNotificationProvider

Но ничего не изменилось, видимо где-то этот новый провайдер надо подключить?

Добавили
вот такую строчку в sql
insert into NotificationProvider
(ClassName,Type)
values('Terrasoft.Configuration.UsrProblemNotificationProvider',1)
Уведомления для проблем включены.
По аналогии поступим со остальными разделами.
Но очень странно, конечно, что провайдеров изначально не было
Спасибо)

Показать все комментарии

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

Ниже описана не "защита от дурака", а очень простой пример вопроса, который будет уточнять необходимость сохранения изменений.

В обработчик нажатия "ОК" добавлен следующий код:

         if (Dataset.State == dstEdit){
                   var AreYouSureYouWantToSaveChanges = "Сохранить внесенные изменения?";
                   
                   if (Dataset.Values('ContractNumber') !=
                   Dataset.DataFields.ItemsByName('ContractNumber').OldValue) {
                           
                                      if (ShowConfirmationDialog(AreYouSureYouWantToSaveChanges) != mrYes){
                                               return;
                                      }                
                   }
         }

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

/system/files/03-07-2012_22-57-56.png

Нравится

Поделиться

1 комментарий

Хорошо бы этот скрипт дополнить процедурой на изменение данных, т.е. если данные поменялись, то задать вопрос о сохранении изменений, в противном случае просто закрыть без сохранения изменений. И этот скрипт поместить в scr_BaseDBEdit.

Показать все комментарии

В этом блоге я хочу принципиально описать темы которые, надеюсь, интересны продавцам, внедренцам и менеджерам.
Трудности с которыми сталкивались клиенты (суть проблем которые они описывали), совершенно отчетливо показали, что результативность бизнеса базируется на следующих "трех китах":

  1. Люди
  2. Технологии
  3. Методология внедрения изменений (технологий)

Подробности ниже:

Люди:

Тут, думаю все понятно, успех любого дела начинается с того, кто им будет заниматься.
Интересны следующие "детали":

  1. Практики подбора персонала
  2. Мотивация
  3. Оценка компетенций и управление развитием
  4. Построение отношений

Технологии:

Это самая обширная тема, тут в принципе может быть все. Строго говоря, то что я описал выше тоже технологии, но для стройности теории я их вынес отдельно. Любая деятельность в организации, построена, по определенной технологии.

Когда я, как продавец, выяснял задачи клиента, в первую очередь меня интересовал рабочий процесс.Если руководитель хорошо понимает процесс, (я имею в виду, что делается, зачем, почему так а не по другому и что нужно поменять), тогда задачи на автоматизацию очевидны и такому клиенту продать проект относительно легко. Иногда, руководители не могут внятно ответить на эти вопросы, точнее говорят, что это сложившаяся с опытом практика (так принято (традиция), так сказал босс повыше (головная компания) или самое страшное "у нас опытный персонал который сам знает что делать"), тогда мне приходилось самому разбираться, что не работает, что можно поменять и где в этом всем место CRM системы.

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

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

Отлаженный рабочий процесс - это "ноу хау" организации и ее собственность. Часто говорят, что клиент которого привлек менеджер по продажам, - это не его собственный клиент (хотя менеджер может считать иначе), а клиент компании, и информация о нем и ньюансах отношений, должна остаться в компании даже в случае ухода этого менеджера.

Точно также квалификация и компетенции руководителя должны принадлежать не людям, а организации в виде рабочего процесса. Организация такой работы, которая приносит нужные результаты, как бы и без "участия" руководителя, и есть главный критерий его успешности. Только этом случае руководитель сможет заниматься стратегическими задачами, а не утопать в оперативных вопросах.

Отлаженный рабочий процесс позволяет снизить требования к персоналу. Если раньше нужны были "звезды", способные решать каждый день ту или иную проблему, то теперь сотрудники могут принимать рутинные решения руководствуясь формализованным регламентом. Безусловно, все предусмотреть невозможно, но если руководитель сталкиваясь с проблемой которая имеет определенный шанс повториться в будущем и в которой приходится принимать нестандартное (еще не описанное) решение, потрудится описать этот кейс, тогда появится набор (библиотека) лучших практик, которой сможет воспользоваться даже исполнитель. И наоборот, когда нет технологии, бизнесу приходится нанимать "специалистов", которые вроде как сами знают, что делать. В результате фактическое руководство переходит в руки этих самых "специалистов", каждый из которых сам знает что ему делать, как и когда. А чаще всего имеют представление и сами решают о том, что можно делать кое-как или совсем не делать.

Предлагаю в нашей работе выделить следующие технологии:

  1. Продажи (коробок и проектов)
  2. Реализации проектов
  3. Вывод нового продукта (отраслевого решения)

Методология внедрения изменений

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

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

Нравится

Поделиться

5 комментариев

Саша, так ведь вроде есть документ или ряд документов с лучшими нашими практиками (по крайней мере, по внедрению вроде было). Или это не то?

Саша, регулярно читаю твои сообщения.
Предлагаю четко выделить концепцию.
Бытует такое мнение, что если концепция удачна, она должна умещаться на обычной салфетке.
Вот попробуй в 140 символов, как в твитерре, выразить, что ты хочешь сделать и как оно поможет нам, а то "многабукфф" и "я потерялася" (с) :wink:

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

Коллеги, спасибо.
Идею я опубликую в разделе "Идеи".

Юра, анекдот:

— Нет, нет, нет! — кричит главный редактор своему репортеру, — статья слишком длинная! Выбросьте все ненужные подробности!
Через полчаса репортер приносит текст:
— Мистер Хэнкс вел машину со скоростью 100 миль в час по скользкому шоссе. Похороны завтра в 15 часов.

Показать все комментарии