OTRS.ru

Читал долго, но так и не понял, чего хотите. Но что-то подсказывает, что неправильно понимаете смысл ACL в OTRS. ACL не добавляет прав, тем более никуда ни в какую очередь ничего не отправляет. ACL "урезает" возможности, представленные другими механизмами OTRS. чтобы клиент ,если он в группе UMSKP, ...

Проверять лень. Но.
Если вам нужно направлять сообщение клиенту (а не уведомление о каком-либо событии), для заметок используйте не режим Заметки, а операцию Ответить. Это тоже заметка, но с типом Внешний емайл.

В настройках для клиента такого нет, только для агентов.
В Howtos есть пара тем "Создание шаблонов заявок", это лучше, чем иметь всего один шаблон для всех клиентов.

Оно так и работает. Главное, чтобы в ответе не портили тему с номером заявки

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

Ticket::Frontend::AgentTicketCompose###StateDefault

Значение по умолчанию: open

Задает следующее состояние по умолчанию для заявки при создании ответа/сообщения в интерфейсе агента.

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

svarog.be писал(а): ↑

19 апр 2019, 06:16

По описанию он даёт возможность агентам создавать отчёты.

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

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

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

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

Framework → Core → SystemID
"Задает идентификатор системы. Каждый номер заявки и http-сеанса содержит его. Это дает уверенность в том, что заявки только вашей системы будут обработаны как ответы (дополнения) (может быть полезно при связи между двумя установками OTRS)".

Что в истории таких заявок?

Это не "префикс", а идентификатор вашей системы. Полезно, если используется более 1 системы. Странно, если система будет менять свой SystemID в зависимости от числа заявок.
Можно отключить в Framework-Core

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

Письма же не пропадают. Вот и забейте.

Да уж, странные у вас агенты. Впрочем, встречал. Прилетело агенту письмо - новая заявка в очереди. -> Ответ агента на заявку емылом с тэгом #get в теле письма -> OTRS исходя из тэга Вешает заявку на агента и уведомляет об этом клиента и агента -> Агент отработав заявку отвечает на письмо о назначени...

Непонятно, что вы хотите от таких клиентов. Заявки создать по почте они могут, написать заметку в существующую заявку - тоже. Не могут закрыть? Ну так и не нужно, не их это дело.

Подскажите, где можно установить время, в течение которого клиент может вернуть заявку на доработку? Чтобы в работу не возвращались заявки полугодичной давности. Как вариант - запретить клиенту "возврат" закрытых заявок и использовать не закрытие, а автозакрытие через желаемое вами время. Мы исполь...

Борис писал(а): ↑

14 фев 2019, 11:58

через фильтры, не то что хотелось бы

Так не умею, что даже и не хочется.
Или есть иная причина?

Курите фильтры Postmaster в админке

Заведите тему в нужной ветке форума и четко опишите проблему. Я так и не понял, чего именно вы хотите.
На всякий случай: агенты и клиенты - разные категории пользователей, и для них нужны свои собственные описания бэкэндов и способов авторизации в конфиге.

Если способ авторизации в конфиге не указан, она осуществляется во внутренней БД. Если указали AD/LDAP - будет AD/LDAP. Чтобы было и то, и другое - в конфиге должно быть по 2 блока описаний источников данных и способов авторизации (с цифирками 1 и 2).

Забавная логика работы с заявками
- клиент сутки не имеет информации о состоянии заявки
- после чего система врет клиенту, что о нем не забыли.

В принципе через планировщик и управление уведомлениями что-то подобное можно организовать. Но точно незачем.