OTRS.ru

Уважаемые коллеги,

Помогите разобраться со следующей ситуацией. На тестовой машинке проапгрейдил OTRS 3.3.4 до 3.3.8, перенес все измененные файлы и конфиги.

У меня по рекомендации из этого же форума сделана следующая модификация:

/opt/otrs/Kernel/Modules/AgentTicketPhone.pm
Ищем строки примерно 1333-1341

Код:
# else set owner to current agent but do not lock it
else {
$Self->{TicketObject}->TicketOwnerSet(
TicketID => $TicketID,
NewUserID => $Self->{UserID}, меняем на {1}, идентификатор Admin@otrs
SendNoNotification => 1,
UserID => $Self->{UserID},
);
}

Для того чтобы владельцем заявки при создании становился пользователь Admin@otrs, так вот этот код отлично работал в старой версии, а после апгрейда создатель заявки становится ее владельцем. Я уже раз 20 проверил все ли правильно перенес. Ничего не нашел. Что делать?

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

Уж сколько раз твердили миру, да только всё не впрок!
/opt/otrs/Kernel/Modules/AgentTicketPhone.pm - не надо править оригинальные файлы!

А какой способ еще существует кроме как править оригинальные файлы если другими средствами этот вопрос не решается? Правка была взята из этого форума, в ответ на вопрос как установить умолчального пользователя. Помещать в Custom файлы? Тогда чем это отличается от правки оригинального файла? Точно так же не работает.

Вопрос решился вроде. Я взял файл AgentTicketPhone.pm и сделал там такое же исправление. И оно заработало. А вот почему возникает спонтанно поле выбора агента для назначения заявки это загадка пока, файлы Ticket.pm и AgentTicketPhone.dtl у меня с правками из How-to форума, для создания шаблонов. Может файлы версии 3.3.8 тоже имеют какие-то отличия? Ну и еще один баг - я создал статус заявки Выполнена сделав ее тип Открытый. В 3.3.4 все было отлично, новые заявки создавались как новые, а в 3.3.8 новые создаются как выполненные, после блокировки статус не меняется. Хотя в сисконфиге все четко прописано - статус новой заявки new, при блокировке смена new на open.

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

Имеется в виду, что Вы берете оригинальный файл, делаете в нем необходимые правки и, затем помещаете его в кастомную папку имя которой для .dtl файлов указываете в SysConfig. Эта азбука есть в мануале и ее следует выучить как "Отче наш". Для модулей.pm уже есть папка Custom и их следует помещать туда, создавая путь расположения как и оригинального модуля.
И еще. Я обычно до апгрейда проверяю, не изменились ли тесты моих кастомных модулей и шаблонов в новой версии и, лишь после проверки и обновления их, приступаю к апгрейду. Думаю, это правильный путь. Этим Вы гарантируете, что не огребете неприятностей после апгрейда. Ну, или, как минимум сводите их вероятность к минимуму.

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

Я не программист на Perl или HTML, но нормальная программистская логика должна подсказывать, что это может влиять на работу всего модуля в целом или и в другом месте системы.

Да логика правильная, положил в копилку своего опыта...