META

Тикеты

Таблицы

  • issue: Непосредственно сами тикеты. Основная таблица
  • issue_entity: Сущности, доступные для выбора “категории” тикета при создании. Тип объекта, в рамках которого делается тикет. Например тикет может быть по клиенту, медиаплану, сотруднику
  • issue_field: Доп. поля, которые можно навешивать потом на типы тикетов
  • issue_logwork: Трекинг времени по тикетам
  • issue_msg: Комментарии к тикетам, приложенные файлы
  • issue_priority: Справочник приоритетов тикетов
  • issue_status: Справочник статусов тикетов
  • issue_type: Справочник типов тикетов, Тут настраивается доступность типов тикетов для issue_entity, доступность основных или доп полей

Управляющие функции БД

Пользовательские функции для изменения бизнес логики отмечены жирным шрифтом.

  • fill_new_issue_fields: Заполняет исполнителя и участников тикета 
  • get_issue_access: Проверка ACL для доступа к тикету
  • get_issue_type_object_kind_options: Возвращает список options для me-input. Настраивается под сложные запросы, где metaql будет излишне сложен. Далее есть детальное описание работы с этим методом
  • get_issue_type_object_details: Возвращает текст деталей по этому тикету, исходя из его сущности и типа в формате markdown. Используется в модуле Согласование для отображения более полной информации по тому, что нужно согласовать.
  • get_issue_assignee_variants: Возвращает возможных исполнителей для данного тикета в зависимости от типа и сущности, в рамках которой работает. Если возможных исполнителей несколько и пользователь не выберет конкретного при создании тикета, то при добавлении тикета автоматически будет выбран первый из списка.

Системные функции (нельзя менять):

  • get_issue_log_md: Возвращает детали по истории изменений тикета в формате markdown
  • get_issue_type_lego_form: Возвращает meta lego форму дополнительных полей для тикета
  • after_issue_self_change: Триггер для логирования истории изменения тикета
  • after_issue_msg_self_change: Триггер для логирования истории изменения комментариев тикета, а так же добавления участников тикета при упоминании их в комментариях
  • get_approve_status: Получить статус согласованности тикета (с kind=approval)

Получение сложных списков для полей тикетов (get_issue_type_object_kind_options)

Что нужно сделать c вашим me-input:

  • добавить depends
  • добавить refPvmData

Пример элемента со сложной зависимостью от других с подгрузкой данных из get_issue_type_object_kind_options

{
  "id": "test_account",
  "name": "me-input",
  "attrs": {
    "type": "select",
    "required": true
  },
  "label": "Test account",
  "depends": [ 
    "issue_type_id", "object_id", "entity_id", // Эти поля обязательно нужно указать в depends
    // Далее пользовательские поля
    // Знак @ использовать необязательно, но он может помочь вам не писать полный путь зависимости, а просто указать, 
    // что зависимость на том же уровне LEGO иерархии 
    // Подробнее https://developers.devision.io/meta/reference/ui_controls/typedoc/interfaces/_elems_i_me_input_.imeinput.html#depends
    "@.engine as engine", 
    "@.connection_id as connection_id"
  ],
  "refPvmData": {
    "id": "issue_type_object_kind_options",
    "sp": {
      // Обязательно укажите вид зависимости. Как правило это помогает разобраться в при трассировке запроса и в хранике для условий роутинга
      "kind": "test_account" // Обязательно 
    }
  },
  "formHorizontal": true
}

Разновидности типов тикетов

Тип: Согласование (kind=approval)

Используются для реализации механизма согласования объектов. Хорошо подходят для этого так как:

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

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

Для каждого типа согласования следует делать отдельный issue_type, так как для разных типов согласования скорее всего понадобится разная сопроводительная информация из get_issue_type_object_details**.**

Для добавления нового типа согласования на сущность нужно:

  • Добавить основное поле для сущности в issue_field, если поля еще нет

  • Добавить сущность в issue_entity, если ее там нет и указать основное поле в issue_field_id

  • Добавить запись в issue_type

    • для нужной entity 
    • c нужными application_ids
    • как правило поле issue_fields заполнять не нужно
    • mods для согласований обычно {assignee,deadline,description,priority}
    • kind=approval
    • is_helper=true
    • allowed_roles={meta.role.dev} потому, что вам сперва нужно все проверить и только потом открывать тип тикета на всех пользователей

  • Реализуйте обработку получения деталей этого типа тикета в get_issue_type_object_details

  • Реализуйте получение списка возможных исполнителей в get_issue_assignee_variants

Тип: Задача (kind=issue)

Самые обычные типы тикетов. Ничего примечательного.

Могут обрабатываться роботом или человеком.