21 lines
2.9 KiB
Markdown
21 lines
2.9 KiB
Markdown
|
||
|
||
- прописать в таблице “распределение данных” внутренние названия всех полей
|
||
- собрать миграцию данных опциональных полей для ПГО1 (таблица field_optionals)
|
||
- собрать миграцию данных ПГО1 для “пищевой продукции/биологических материалов”,
|
||
- доработать и протестировать API-запрос к бэку для возврата опциональных полей
|
||
- Фронтенд:
|
||
- сделать скрытыми все поля с лейблами кроме обязательных согласно таблице “распределение данных” (hidden). Возможно, придётся делать блоки поля с лейблом для удобства скрытия.
|
||
- сделать тег типа у каждого поля/лейбла – “основное”, “опциональное”, “пользовательское”
|
||
- Функционал показа для новой заявки:
|
||
- запрос при каждом изменении селектов “Тип ОИ” и “Группа ОИ”
|
||
- запрос к API fields/optional, передавая group_id и object_type
|
||
- *доработка под тариф в будущем*
|
||
- после ответа от API отображать полученный список полей (меняем статус видимости)
|
||
- Функционал показа существующей заявки:
|
||
- Массив опциональных полей сразу же запрашивается на этапе формирования данных для фронта для каждой заявки (так мы сможем просто включать поля в БД после доработок)
|
||
- Все данные опциональных полей перемещаются в поле details сущностей согласно таблице “распределение данных” (на данном этапе либо к request, либо к incoming_object). Это очень простой json массив \[поле => значение\]
|
||
- Поля включаются так же, как и в новой заявке
|
||
- Следовательно все данные должны затянуться автоматически из массивов details и показаться в полях
|
||
- Параллельная подготовка бэкенда для распределения и отдачи данных из массивов details + доработка миграций, чтобы переместить динамические данные в details
|
||
- Подготовка бэкенда к функционалу сохранения динамических полей БЕЗ ВАЛИ |