Детали задачи
-
История
-
Решение: Готово
-
High
-
Не заполнено
-
Не заполнено
-
Не заполнено
-
ent 01.03-12.03.2021
Описание
Управление статусами должно происходить только в типе кейса (вкладка Roles).
Сейчас в типе кейса нужно ссылаться на типы из журнала типов. Пользователь не должен думать об этом.
Необходимо добавить поддержку статусов из типов.
Статус в конфигурации типа - это структура примерно следующего содержания:
{ "id": "draft", "name": { "ru": "Черновик", "en": "Draft" } }
Нужно чтобы в кейсе можно было не создавать статусы в виде нод, а использовать настройку из типа.
- Проверить и заменить все места где используется ассоциация icase:caseStatusAssoc и любая работа со статусами как с нодами на использование сервиса CaseStatusService (добавить методов если нужно).
- Дорбавить аспект со свойствами ecos:caseStatusProp и ecos:caseStatusBeforeProp с типом текст
- При получении статуса у документа сначала смотрим на свойство ecos:caseStatusProp и если оно пустое или null, то берем статус из ассоциации icase:caseStatusAssoc
- В свойствах для статуса (п.2) должен храниться id статуса (например, “draft”)
- В методах, которые возвращают 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 сценария:
- Когда происходит поиск по ноде статуса (атрибут icase:caseStatusAssoc) если нодреф реальный (начинается на workspace), то получаем его ID и делаем условие (не точное. просто для примера) (icase:caseStatusAssoc_added:”workspace://…” OR ecos:caseStatusProp:”draft”).
- Если нодреф виртуальный (et-status://…) или к нам пришел запрос на поиск по ecos:caseStatusProp, то берем id статуса, ищем через сервис nodeRef статуса и если такой нашелся, то делаем аналогичный п.1 запрос. Если такого статуса нету, то делаем просто условие ecos:caseStatusProp:”draft”
- Если пришел запрос на поиск по атрибуту “_status”, то действуем аналогично п.2, но проверяем какой именно статус пришел (workspace://… или et-status://…)
Нужно добавить EcosStatusEdge, в котором реализуем метод getOptions() в котором через TypeDefService получаем список статусов для текущей ноды по её типу (для получения типа используем CaseTypeService). В методе getType нужно возвращать “options”.
В AlfNodeRecord методе getEdge если атрибут равен _status, то возвращаем EcosStatusEdge
После этого нужно поменять в коробочных журналах атрибут статуса на _status и в фильтрах настроить выбор статуса из выпадающего списка.
Вложенные файлы
Вложенные файлы
Связи запроса
- blocks
-
ECOSCOM-3831 Journal filter must show statuses only for current request
- New
- Children
-
ECOSCOM-4101 Ecos statuses. Rework fast search.
- New
-
ECOSCOM-4100 Rework StatusRecords
- Готово
-
ECOSCOM-4102 Ecos statuses. In journal should display statuses from the ECOS case type.
- Готово
-
ECOSCOM-4103 Ecos statuses. Rework TaskDataListenerUtils.fillDocumentData() for support ecos statuses
- Готово
-
ECOSCOM-4123 NodeRef of virtual status must contain id of type
- Готово
- mentioned in
-
Page Загрузка