Зависимость видимости полей от значения других полей

Аватара пользователя
Герасимов Андрей Владимирович
Сообщения: 61
Зарегистрирован: 26.04.2016 20:46

Зависимость видимости полей от значения других полей

17.08.2016 10:29

Добрый день. Предлагаю реализовать механизм настройки видимости полей задачи в зависимости от значения других полей.

Кейс:
  • задача = договор
  • существует несколько видов договоров
  • у каждого вида договора свой набор параметров
  • создаем кастомное поле - вид договора
  • создаем наборы полей соответствующие каждому виду договора
  • создаем задачу-договор, указываем вид, видим на форме набор полей соответствующий выбранному виду
Может показаться что это можно решить шаблонами задач, но
  • Реестр задач-договоров в виде списка задач или отчета удобнее реализовать отбором по одному шаблону чем по нескольким
  • В примере приведена простая зависимость от одного поля, но зависимости могут быть сложнее. Например, выбираем тип оплаты (предоплата, кредит, предоплата+кредит) и появляются поля для указания сроков этапов оплаты

Аватара пользователя
Андрей Гринюк
Сообщения: 171
Зарегистрирован: 19.01.2016 18:50

17.08.2016 19:14

Если по сути договоры разные, то мне кажется правильней использовать "Шаблоны задач". А вот удобно или не удобно - это не много другая задача.

А вот с оплатой это очень хороший аргумент. Приведу скриншот с другой системы Pyrus.com на который мы раньше работали. Конструктор формы там, мне кажется, лучше. И сама форма получается более функциональней (опциональней). Планфиксу стоило бы присмотреться к ней.
Вложения
Снимок.PNG
Конструктор формы в Pyrus.com

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4127
Зарегистрирован: 06.06.2012 13:54

22.08.2016 13:17

Действительно, на текущий момент это можно сделать только при помощи разных шаблонов для каждого из вариантов (и подваринтов) задачи. Минусы описаны правильно: много шаблонов, сложно выбирать нужный из обширного списка при создании задачи. А каждый подвариант (вроде того, что в примере с оплатой/предоплатой) либо увеличивает количество неиспользуемых полей в шаблоне, либо увеличивает количество самих шаблонов (отдельно для оплаты, отдельно для предоплаты и т.д).

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

Еще один момент, который мне пока непонятен - сейчас шаблон задачи является удобным идентификатором ее типа, это широко используется в фильтрах (отобрать только задачи определенного типа) и автоматических сценариях (разные сценарии для задач разного типа). Если свести много шаблонов в один, изменяющийся в зависимости от выбранных полей, что будет служить таким идентификатором? Первое, что приходит в голову - условие "содержит значение в поле <таком-то>" (например, содержит значение в поле "предоплата" - значит это предоплата). Но так сразу увеличивается сложность условий (и, соответственно, падает удобство их восприятия и скорость отбора данных), если искомый тип задачи находится в глубине дерева вариантов - то есть, если нужно найти задачу в которой поле такое-то содержит значение, и в поле таком-то есть значение, и в поле таком-то.... и так далее. И вот тут непонятно, будет ли это в итоге удобнее по совокупности факторов, чем текущий подход с отдельными шаблонами.

За пример с Пирусом спасибо, он хорошо показывает, как может быть настроено простое условие. А что касается более сложных, есть еще какие-то механизмы? Или все строится только на этом варианте настройки, просто одно "условное" поле может ссылаться на другое такое же, и на этом строятся сложные варианты поведения формы? Если второе, то есть ли опыт построения таких сложных форм? Хочется заранее понять, насколько удобно работать с таким подходом в сложных случая, как воспринимаются мозгом эти "ссылки на ссылки", есть ли визуальное понимание, как в итоге будет выглядеть форма для того или иного случая?

Аватара пользователя
Геннадий Горбунов
Сообщения: 27
Зарегистрирован: 23.01.2017 19:37

Скрывать ненужные поля шаблона задачи - в зависимости от значения кастомного пол

17.03.2017 18:06

Столкнулись с одним неудобством:
Мы работаем с однотипными задачами. В зависимости от значения кастомного поля "Тип задачи" должны выводиться разные поля. Для одного типа задач достаточно 3-х полей, для другого - порядка 10-ти.

Приходится создавать неоправданно большое количество однотипных шаблонов...
Хотя разница между этими шаблонами - только в количестве выводимых на обозрение пользователя полей на основной панели шаблона!

Наше предложение - дать возможность скрывать ненужные поля шаблона задачи в зависимости от значения кастомного поля (или системного поля Статус).

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4127
Зарегистрирован: 06.06.2012 13:54

18.03.2017 17:14

Такие предложения периодически звучат, но на наш взгляд такой подход привел бы в существенному усложнению процесса настройки шаблонов, т.к. приходилось бы в каком-то виде задавать эти зависимости. Если мне не изменяет память, в одном из обсуждений кто-то предлагал вариант такой настройки, подсмотренный в какой-то другой системе - но сейчас попробовал найти эту ветку и не получилось. Возможно, он же или кто-то другой откликнется в этом обсуждении и продолжим поиск решения.

Аватара пользователя
Геннадий Горбунов
Сообщения: 27
Зарегистрирован: 23.01.2017 19:37

21.03.2017 21:23

Спасибо, Андрей за отклик!

Аватара пользователя
Дмитрий Авдошенков
Сообщения: 1
Зарегистрирован: 26.04.2017 12:32

Автоматическая активация полей в проекте при выполнении условия в другом поле

26.04.2017 12:46

Настраиваю шаблон проекта и столкнулся с необходимостью следующего функционала: в рамках одной панели есть различные поля и некоторые из них должны появляться только после того, как выбрано определённое значение в предыдущем поле. Допустим, у клиента может быть хостинг оформлен через нашу компанию, тогда необходимо уточнить - произведена ли оплата, есть ли SSL-сертификат и проч. 
Сейчас приходится создавать кучу полей, задавать им значения по умолчанию, из-за чего, во-первых, карточка проекта разрастается, а во-вторых, указывая значения по умолчанию есть риск потом не заменить значения на актуальные, если в поле, значение которого проверяется, значение изменится на соответствующее условию.

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4127
Зарегистрирован: 06.06.2012 13:54

29.04.2017 12:33

Перенес в общую ветку и запрос Дмитрия (выше) на похожий функционал для проектов. Будем стараться держать все в одной корзине, может со временем это приведет к выработке решения.

Аватара пользователя
Павел Лысанов
Сообщения: 1
Зарегистрирован: 15.05.2017 12:06

15.05.2017 12:14

Добрый день!
Дмитрий Гончаренко: "..затрагивается структура внутреннего хранения данных в системе, а это всегда больно переделывается.."
А вы не пробовали использовать концепцию EAV, чтобы "физическая" структура данных была стабильной?

 

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4127
Зарегистрирован: 06.06.2012 13:54

27.05.2017 12:02

Здравствуйте, Павел!
Пробовали такой подход на справочниках. К сожалению, при всей его привлекательности столкнулись с тем, что система получилась слишком медленной в работе и нам пришлось переделать справочники полностью на обычные таблицы, чтобы получить возможность строить индексы и ускорять выборки данных.

Ответить