Возможность настройки обновления метаданных для конкретных кастомных полей

Что не так:
В текущей реализации существует возможность настройки источника метаданных тест-кейса - из тестопса (данные хранятся в БД и не изменяются при загрузке результатов прогона) и из результатов теста. Однако настройка является дифференцированной только в части базовых атрибутов тест-кейса - имени, описания и т.д. Кастомные поля обрабатываются единообразно - либо все в Бд, либо все из результатов теста.
Фактически, это означает, что все кастомные поля нужно держать в коде тестов, что усложняет их ведение. Для некоторых полей такая информация в коде является избыточной (например, имя коллекции Postman). Также возрастает риск банальных ошибок - опечаток или указания неверного имени кастомного поля.
С учётом того, что структурирование большой тестовой базы фактически зависит от кастомных полей, это делает работу менее комфортной и более трудозатратной.

Что предлагается:
Предусмотреть в рамках проекта возможность настройки для всех кастомных полей проекта источника данных (пока что - "тестопс" и "результаты"). Например, разрешив в панели "Настройки обновления метаданных" создание правил вида сf["Кастомное_поле"]. Или разделив её на две секции (которые можно отображать рялом - потому что страница по факту практически пустая).
Кроме того, предлагаю рассмотреть вопрос об исключении из отображения правил вида <атрибут> from_test_result. Если мы знаем, что это и так по умолчанию, такие правила не более, чем информационный шум, совершенно ненужная информация. Вот если бы сразу отображались полные перечни того, что настраивается в отношении источника обновления, и без явного указания "по умолчанию" - тогда да, в этом был бы смысл.

Что улучшится:
Появится возможность вынести часть информации, нужной для структурирования тест-кейсов, непосредственно в ТестОпс, оставив в коде тестов только те кастомные поля, которые добавляют к самому коду полезную для тестировщика информацию, а не дублируют то, что и так очевидно. Например, в случае стуктурирования тест-кейсов по функционалу код теста сам по себе отражает тестируемый функционал (особенно с учетом наименования/описания).
Уменьшится количество доп. информации и объем тестовых коллекций, с ними станет удобнее работать, не нужно будет вводить "руками" нужные кастомные поля (можно будет добавлять их просто перетаскиванием в дереве - что быстрее и существенно в меньшей степени error-prone).