23 мая 2018 в 15:07
Приветствую!
Помогите пожалуйста решить такую задачу.
Исходные данные:
1. Есть словарь с терминами таксономии:
-Категория услуг 1
-Категория услуг 2
2. Есть тип материала Анкета, при создании которой зарегистрированный пользователь выбирает термины таксономии этих Категорий услуг, которыми он занимается.
Это либо все 2 Категории услуг сразу, либо только Категория услуг 1 или только Категория услуг 2
3. Есть тип материала Прайс-лист, в котором созданы поля для ввода значений цены этим зарегистрированным пользователями.
Прайс лист:
Категория услуг 1
- услуга №1 - цена 1 руб
- услуга №2 - цена 1 руб
Категория услуг 2
- услуга №1 - цена 1 руб
- услуга №2 - цена 1 руб
ВОПРОС: Как сделать так, чтобы если пользователь выбрал только термин Категория услуг 1 при создании Анкеты, то ему показывались именно только поля ввода цен для Категории 1 в типе материала Прайс,. Т.е. поля ввода цен для услуг Категории 2 не показывались.
Понимаю, что здесь нужно использовать Reference и т.д., но как это сделать не знаю.
Заранее спасибо за помощь!
Комментарии
Я бы решал вопрос программно. По крайней мере - я не припоминаю никаких "кликабельных" средств навскидку. Может, что-то и можно нарулить путём нагромождения пачки модулей, но это какой-то изврат, имхо.
entity reference в общем-то необязательно, если у пользователя заведомо только по одному материалу типа "Прайс" и типа "Анкета". Их nid'ы можно получить программно по uid автора. Собственно, программно всё сводится к одному хуку hook_form_alter()
Conditional Fields
Я, кстати, было подумал о них, но разве conditinal fields могут работать с полями другой (т.е. неактивной) формы и вообще другого типа материала? Я что-то не припоминаю навскидку.
через какой-нить inline entity form лихо завернёт и сможет.
Невнимательно прочел, да Conditional Fields тут не помогут.
Всем спасибо за мнение!
Но хотелось бы более определённого решения
Более определенное - подумать/пересмотреть структуру.
Добавьте хоть скрины материалов
Вот набросал если поможет вам скриншот https://yadi.sk/i/sFdzIIeH3WRdBY
Гарантированное определённое решение нужно писать. Могу сориентировать как:
1. Создаём модуль
2. В нём хук hook_form_alter()
3. В этом хуке проверяем, что текущая форма - именно форма редактирования материала "Прайс"
4. В этом же хуке читаем uid пользователя и получаем по нему из БД ноду типа "Анкета". Проверям состояние полей Категории услуг (1 и 2). Для тех из них, которые не определены (т.е. не выбраны) - ставим атрибуты соответствующих полей формы "Прайс" в #access = FALSE (что скрывает эти поля формы)
5. Bingo.
Код писать для меня не вариант. Я не знаю толком PHP И мне кажется что такое возможно реализовать с помощью модулей
Мне кажется, что нет.
PS. Если что - пишите в личку, за вознаграждение сбацаю "определённое" программное решение.
Rules Forms Support можно попробовать вместо кода
Спасибо! попробую покопаться в нём.
Этот модуль не решает вопрос...
через conditions - решается.
http://prntscr.com/jlza4k
Даже если поля раскиданы по разным типам материалов?
заверните зависимые поля в fieldset
Вам надо создать все fieldset для всех желаемых типов материалов. A conditions покажет только те, которые выбраны на форме...
Посмотрите пожалуйста вот этот модуль https://www.drupal.org/project/field_conditional_state
Видео https://youtu.be/BvboSBIpitc
Он по идее решает задачу. Может подскажете как мне создать зависимость между полем и термином таксономии из разных типов материала?
Вы в Conditionаl кажется нашли как это сделать. Может и здесь решите эту задачу
_webform_select_options_info
Это тоже может сильно пригодиться
Спасибо за помощь!
А _webform_select_options_info зачем нужен? У нас же не вебформа.
Нашёл модуль, который по идее тоже может помочь решить задачу Field Conditional States
Вот видео про него для Drupal 8 на ютубе https://youtu.be/BvboSBIpitc
Для 7 версии он есть тоже.
Модуль должен помочь, зависимости выставляет
Осталось только догадаться как связать поле с термином таксономии в другом типе материала.
Т.е. по сути осталось решить основную проблему? )
Я повторю свой совет: не морочьте себе голову. Начните сами писать модуль, быстрее доберётесь до результата, даже если плохо знаете PHP. Да и в будущем пригодятся навыки.
На друру кроме свидетеля секты "хлебные крошки на вьюс", появился свидетель секты "делаем всё через вебформ".
Как я вижу решение задачи. Понадобится Inline Entity Form (ief), Entity Reference и всё.
1. Тип материала "Анкета" заполняется как заполнялось.
2. Добавляется тип материала "Прайс для категории".
3. В него добавляется поле для выбора категории. И тут самая суть - значения для поля можно фильтровать с помощью вьюс. Создаётся вьюха, добавляется связь с текущим пользователем, добавляется связь с материалом "Анкета" этого пользователя, и выводятся только те термины, которые выбраны в анкете.
4. В тип материала "Прайс" добавляется связь с материалом "Прайс для категории", виджет IEF.
Ребята, в топике какой-то ад.
Совет делать через вебформ - не менее странный, чем совет делать через параграфы, например.
Давайте тормознём со странными предложениями, я и так планировал скоро рассказывать историю магазина, где цены к товарам записываются в alt картинок в imagefield.
Я считаю, что вариант @fairrandir самый близкой к правде, об IEF я сразу упоминал.
Но я бы, конечно, пересматривал структуру.
Я бы сказал - это пограничный, маргинальный подход - учитывая прямое, изначальное назначение вебформ. Случай, когда "не совсем то" может изрядно запутать сборку и стать в дальнейшем проблемой для модификаций.
Я, кстати, лайкнул решение fairrandir, хотя, как писал в снесённой ветке, не фанат такого подхода. Но это хоть что-то внятное из предложенных "мышечных" способов.
Я как-то не могу понять (и тут вопрос, наверное, в первую очередь к ТС): какой спортивный интерес заключён в наруливании довольно замороченного функционала с помощью пачки готовых модулей, когда в итоге по суммарным затратам времени проще самостоятельно написать не такой уж сложный модуль на 50-70 строк кода, который решит все проблемы на раз-два?
Всё равно админы сайтов как правило приходят к необходимости решать какие-то узкие задачи кодом и со временем осваивать Drupal API в той или иной степени приходится волей-неволей. Я не говорю о реально сложных задачах, где нужен уже спец-программист.
Да я бы и сам предпочёл решение кодом, например как в вашем комменте.