Files
SergObsidian/WORK & PROJECTS/Mol/Планы и диаграммы/Заказы/Динамические поля/Динамические поля Заявок (декомпозиция) 2026.02.md
2026-02-12 11:57:29 +05:00

4.1 KiB
Raw Blame History

  • прописать в таблице “распределение данных” внутренние названия всех полей

  • собрать миграцию данных опциональных полей для ПГО1 (таблица field_optionals)

  • собрать миграцию данных ПГО1 для “пищевой продукции/биологических материалов”,

  • доработать и протестировать API-запрос к бэку для возврата опциональных полей

  • Фронтенд:

    • сделать скрытыми все поля с лейблами кроме обязательных согласно таблице “распределение данных” (hidden). Возможно, придётся делать блоки поля с лейблом для удобства скрытия.
    • сделать тег типа у каждого поля/лейбла “основное”, “опциональное”, “пользовательское”
    • Функционал показа для новой заявки:
      • запрос при каждом изменении селектов “Тип ОИ” и “Группа ОИ” к API fields/optional, передавая group_id и object_type
        • доработка под тариф в будущем
      • после ответа от API отображать полученный список полей (меняем статус видимости)
    • Переписать миграции для генерации информации тестовой информации не в полях, а в “details” связанных сущностей
    • Функционал показа существующей заявки:
      • Массив опциональных полей сразу же запрашивается на этапе формирования данных для фронта для каждой заявки (так мы сможем просто включать поля в БД после доработок)
      • Все данные опциональных полей перемещаются в поле details сущностей согласно таблице “распределение данных” (на данном этапе либо к request, либо к incoming_object). Это очень простой json массив [поле => значение]
      • Поля включаются так же, как и в новой заявке
      • Следовательно все данные должны затянуться автоматически из массивов details и показаться в полях
  • Параллельная подготовка бэкенда для распределения и отдачи данных из массивов details + доработка миграций, чтобы переместить динамические данные в details

  • Подготовка бэкенда к функционалу сохранения динамических полей БЕЗ ВАЛИДАЦИИ (прототип мягкого сохранения)

    • Фронтенд+бэкенд — обеспечение мягкого сохранения без валидации всех данных в правильные распределённые таблицы и details
  • Система валидации динамических полей.

    • Поля из обязательной валидации выпиливаются в опциональную.
    • Прописываются правила валидации в БД полей через миграции (правила/сообщения)
    • Движок валидации (принимаем список динамических полей и валидируем)
      • Здесь каким-то образом надо обеспечить обратную связь с фронтом для подсветки неверных полей + сообщений
  • Тестирование в комплексе