Загрузить изображение для проекта: 'Citeck Community'
  1. Citeck Community
  2. ECOSCOM-4073

Status management is only in the case type

    XMLWordДля печати

Детали задачи

    • Icon: История История
    • Решение: Готово
    • Icon: High High
    • Community 4.0rc2
    • Не заполнено
    • Не заполнено
    • Не заполнено

    Описание

      Управление статусами должно происходить только в типе кейса (вкладка Roles).

      Сейчас в типе кейса нужно ссылаться на типы из журнала типов. Пользователь не должен думать об этом.

      Необходимо добавить поддержку статусов из типов.

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

      {
        "id": "draft",
        "name": {
          "ru": "Черновик",
          "en": "Draft"
        }
      }

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

      1. Проверить и заменить все места где используется ассоциация icase:caseStatusAssoc и любая работа со статусами как с нодами на использование сервиса CaseStatusService (добавить методов если нужно).
      2. Дорбавить аспект со свойствами ecos:caseStatusProp и ecos:caseStatusBeforeProp с типом текст
      3. При получении статуса у документа сначала смотрим на свойство ecos:caseStatusProp и если оно пустое или null, то берем статус из ассоциации icase:caseStatusAssoc
      4. В свойствах для статуса (п.2) должен храниться id статуса (например, “draft”)
      5. В методах, которые возвращают nodeRef статуса и при отсутствии nodeRef (если мы нашли статус в свойстве, то у нас только id статуса) возвращаем следующий нодреф:

      et-status://123e4567-e89b-12d3-a456-426655440000/draft

      et-status - константа

      123e4567-e89b-12d3-a456-426655440000 - uuid документа (documentNodeRef.getId())

      draft - идентификатор статуса

      Данный вид nodeRef не будет работать с nodeService и будет только существовать виртуально. По этой причине важно чтобы вся работа со статусами велась через сервис caseStatusService

      За примером можно посмотреть сервис caseRoleService. Там производилась аналогичная миграция.

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

      В PredicateToFtsAlfrescoConverter нужно предусмотреть 3 сценария:

      1. Когда происходит поиск по ноде статуса (атрибут icase:caseStatusAssoc) если нодреф реальный (начинается на workspace), то получаем его ID и делаем условие (не точное. просто для примера) (icase:caseStatusAssoc_added:”workspace://…” OR ecos:caseStatusProp:”draft”).
      2. Если нодреф виртуальный (et-status://…) или к нам пришел запрос на поиск по ecos:caseStatusProp, то берем id статуса, ищем через сервис nodeRef статуса и если такой нашелся, то делаем аналогичный п.1 запрос. Если такого статуса нету, то делаем просто условие ecos:caseStatusProp:”draft”
      3. Если пришел запрос на поиск по атрибуту “_status”, то действуем аналогично п.2, но проверяем какой именно статус пришел (workspace://… или et-status://…)

      Нужно добавить EcosStatusEdge, в котором реализуем метод getOptions() в котором через TypeDefService получаем список статусов для текущей ноды по её типу (для получения типа используем CaseTypeService). В методе getType нужно возвращать “options”.

      В AlfNodeRecord методе getEdge если атрибут равен _status, то возвращаем EcosStatusEdge

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

      Вложенные файлы

        Активность

          Люди

            aleksey.zaytsev Aleksey Zaytsev [X] (Неактивный)
            alexander.nemerov@citeck.ru Alexander Nemerov
            Голоса:
            0 Голосовать за эту задачу
            Наблюдатели:
            3 Начать наблюдение за этой задачей

            Даты

              Создано:
              Обновленo:
              Дата решения:

              Учет времени

                Оценка:
                Первоначальная оценка - 0 минуты
                0m
                Осталось:
                Оставшееся время - 0 минуты
                0m
                Затрачено:
                Затраченное время - 4 дни, 4 часы
                4d 4h