OTRS.ru

Здравствуйте, уважаемые форумчане!
Прошу направить на верную мысль, если такое в OTRS вообще возможно:
Что хардкодить, если нужно, чтобы $Change{PlannedStartTime} присваивалось не значение первого $WokOrder{PlannedStartTime} вообще, а значение первого $WorkOrder{PlannedStartTime}, который не закрыт, а находится в статусе "in progress".
Надеюсь, на понимание

Ваш вопрос противоречит логике - как запланированный старт изменения может быть установлен на непонятное время?

alexus писал(а):Ваш вопрос противоречит логике - как запланированный старт изменения может быть установлен на непонятное время?

Алексей,
прошу прощения, ввел немного в заблуждение
Вопрос сформирую заново:
По умолчанию, запланированный старт изменения = запланированному старту первой задачи. Задач в изменении, к примеру, две.
Как сделать так, чтобы когда первую задачу перевели в статус "closed", запланированный старт изменения стал = запланированному старту второй задачи, которая в статусе "ready".

Опишите конкретный пример такого изменения. Я не понимаю... Начало - это начало. Задачи в изменении - последовательные?

alexus писал(а):Опишите конкретный пример такого изменения. Я не понимаю... Начало - это начало. Задачи в изменении - последовательные?

Алексей,
прежде всего, хочу поблагодарить за консультацию, которую вы предоставили мне в 2015 году по скайпу, так как физически располагаюсь в Алма-Ате (Казахстан). С тех пор, мне удалось многое изменить в процессах управления компанией, и OTRS у нас внедрена уже в "промышленных масштабах". Мы проговорили с вами полтора часа, и я почерпнул много полезного для себя в тот момент!
С глубоким уважением, Сабыр.

А теперь к пояснению:
В нашей деятельности ChangeManagement - процесс управления сервисными контрактами. Мы заключаем очень много подобных контрактов, где предусмотрено своевременное проведение 4-х плановых, вполне стандартных, обслуживаний в год. При таких объемах - актуальным становится планирование инженерного состава к выполнению данных задач. Каждое новое изменение - это новый сервисный контракт, в котором заранее создаются четыре задачи и определяются их примерные (каждый квартал) сроки исполнения. Здесь ITSM_ChangeScheduleOverview - инструмент, который позволяет курирующему менеджеру видеть приближающиеся задачи на ближайший месяц. Установили фильтр для изменений - "in progress" - и вперед!
"НО" заключается в том, что исполненные задачи мы не можем удалять (необходимы для отчетности), но в планировании эти задачи уже не нужны, а запланированный старт изменений так и остается равным запланированному старту первой (уже отработанной) задачи
Сейчас мы выкручиваемся динамическими полями, даты в которые, естественно, приходится прописывать вручную. Все это делаю я, но должно происходить автоматически. Вот и закралась смутная идея в голову - залезть-таки в программный код, хотя в стандартном функционале - OTRS нас полностью удовлетворяет!

Возможно, использование OTRS не в русле ITIL, но двухлетний опыт показал, что такой способ управления сервисными контрактами - в полной мере удовлетворил все заинтересованные структуры компании

Сабыр, спасибо за добрые слова ! Рад, что Вы познали силу)) Я бы посоветовал Вам посмотреть на модуль Calendar. Там можно тикетами вполне прозрачно сделать визуализацию. И не стоит тут с Change мудрить. Мне кажется, что тут Change совершенно избыточен.