Помогайте. Блок "Ближайшие события" в даджесте.

[Creative]

Люди помогайте, туплю конкретно.

Вопросов несколько.
1. Как регулировать период показа в этом блоке? Хочется чтобы показывались тикеты срок напоминания у которых истекает не позже 8 рабочих часов (ну или 24 общих, если отфильтровать только по рабочим часам невозможно).

2. Поставил в ожидание тикет, в очередь технарю, на ближайшие пару часов. Под админом вижу тикет в блоке "ближайшие события", под технарём нет. Где стоит искать косяк?

[ykolesnikov]

SysConfig in Ticket -> Frontend::Agent::Dashboard -->DashboardBackend###0260-TicketCalendar
Возможно, у Вас в в этом параметре указан перечень групп, которым доступна данная информация
Что касается первого вопроса, как решить не знаю, но это как-то соотносится с моей давней мечтой - показывать тикеты, которым установлен срок исполнения - Due Date (динамическое поле) и показывать их за некий определенный срок до наступления. Можно сделать и отдельный дашлет, это описано, но вычислять там нельзя, надо это как-то туда засунуть через другое скрытое поле, куда ставить некое значение, показывающее что срок скоро наступит.

[Creative]

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

Значит теперь встаёт новая задача, автоматизировать процесс создания тикетов, чтобы технарь не продолжал набивать ручками заявки на ближайшие дни, а otrs создавал такие заявки сам ориентируясь на предстоящие события текущего месяца в нужном календаре.
Где-то подобное решение проглядывало (как раз в обсуждениях касающихся планирования работ). Будем искать и ковырять. Календари видимо придётся привязать к учеткам агентов, а клиентов в принципе можно...

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

А по первому вопросу. Я тут ещё подумал. Раз уж привязка идёт по ответственным, то у них есть как правило какая-то рассчитанная статистическая нагрузка.
Если техник за полный рабочий день закрывает не больше 10 плановых работ, то отталкиваясь от этого объёма мы и ставим количество показываемых в дашлете тикетов. Чтобы во-первых не "пугать" технаря , а во-вторых получается ещё одна "псевдоочередь" показывающая предстоящие работы, чтобы технарь зная о предстоящих работах не брал на себя дополнительно инциденты, которыми как правило занимается дежурная смена, и не провоцировал таким образом срыв плановых работ или нарушение SLA по инцидентам.То бишь технарь всегда знает, сколько у него дел есть на ближайшее будущее.
Так что от регулировки сроков я отказался, заменив её установкой лимита показов тикетов в этом дашлете.

[Creative]

Подумал ещё. Надо бы добавить ссылку или фрейм что ли, чтобы технарь, если вдруг собирается перенести запланированную работу на другое время, мог бы поглядеть сразу в своих календарях, что у него когда запланировано.
Вшить бы конечно как-то возможность работать с календарями в OTRS, шикарный симбиоз получился бы. Глядишь в будущих версиях додумаются до этого.

[ykolesnikov]

Где-то еще встречал прием для работы с регулярными заявками (работами).
Создаем заявку. Затем, создаем задачу в Generic Agent, которая запускается в соответствии с регламентом и она заново переводит ее из состояния "Закрыта" в "Новая" или какое-то специально для этого созданное состояние. Она вновь попадает в очередь группы которая производит такие регламентные работы.
Агент по выполнении, вновь ее закрывает и т.п. и т.д. Все ходы по ее выполнению будут в истории и в заметках. Не знаю только есть ли какие ограничения по кол-ву заметок в заявке.

[Creative]

Где-то еще встречал прием для работы с регулярными заявками (работами).
Создаем заявку. Затем, создаем задачу в Generic Agent, которая запускается в соответствии с регламентом и она заново переводит ее из состояния "Закрыта" в "Новая" или какое-то специально для этого созданное состояние. Она вновь попадает в очередь группы которая производит такие регламентные работы.
Агент по выполнении, вновь ее закрывает и т.п. и т.д. Все ходы по ее выполнению будут в истории и в заметках. Не знаю только есть ли какие ограничения по кол-ву заметок в заявке.

Это какая-то записная книжка получается.
В отчётах ни фига не увидим.
К тому же что делать когда договор заканчивается и надо прекращать выполнение работ. Лезть в GA и удалять задачу. Абонентов на поддержке 400-500, у каждого по 4-5 видов регулярных профилактических работ. GA повесится столько обрабатывать, с кроном на пару. За компанию с ними повесится менеджер, которому раньше требовалось вести календарь плановых работ, а теперь придётся рулить малопонятными ему настройками.
Юзабилити ниже плинтуса, статистика вообще в анусе.

Было более изящное решение "где то на просторах НЕродины", где работал демон обрабатывающий в цикле записи из указанного ics соответствующие указанному относительному диапазону времении и он же запускал другой скрипт который непосредственно формировал тикеты. Помнится передача данных в OTRS там выполнялась через SOAP подключение. то есть rpc.pl из набора стандартных скриптов otrs был задействован.

[alexus]

А "недорого" - это как по-Вашему ?

[merkushov]

Теперь осталось только разобраться, как это реализовать на перле или найти того кто это сделает очень недорого

"Недорого" это сколько по вашему?

[Creative]

Недорого, господа, это за такой простенький скрипт до полутора тысяч в настоящее время.
Там дел, насколько вижу, на час работы.
С языком просто плохо знаком, а так глядишь, вообще сам бы реализовал.
Если сойдёмся в цене, и не успею сам разобраться в ближайшее время, буду просить финансирования у начальства.
Некое подобие ТЗ в письменном виде и образец записи календаря в ics предоставлю.

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

[alexus]

Это работы явно не на час. Но готов засечь время, и если кто-то от момента прочтения ТЗ за 1 час все сделает, я готов за это зрелище заплатить 1500 руб., при условии что все работы будут вестись онлайн.
Только в вашем "простеньком скрипте" еще и клиента было бы неплохо устанавливать. И еще вопрос - откуда календарь брать.
Присылайте ТЗ в личку, я оценю стоимость решения.

[merkushov]

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

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

[alexus]

Недостаточно данных для оценки. Может календарь на стене висит, и его сканировать и распознавать надо !

[Creative]

Тема пока прикрылась. Другие вопросы решаем, более важные на данный момент. Так что ТЗ пока не ждите.
Кстати... То решение про которое я говорил ранее, нашлось.
http://www.otrs-blog.org/2010/11/11/pro ... -for-task/
Только набор полей календарей в outlook доставляет некоторое осложнение.

Буду смотреть вариант с другими календарями либо посылку команды на создание тикета не через демона календаря а другим механизмом.
Вариантов множество, от формирования тикетов командой через задание в xstarter (для ряда задач активно использую), до вызова из учетных систем применяемых для работы с договорами клиентов. А там хоть из 1С вызывай, хоть откуда ещё.

Был бы скрипт в который можно передать данные для полей тикета (а он судя по всему в той задаче есть готовый), а откуда его запускать дело пятое.