15 марта 2021 в 20:55
Добрый день!
Прошу подсказки как лучше сделать следующую задачу на D7.
Мне нужно создать 2 двойных поля (модуль double field) не подходит.
Первое двойное поле:
- связка Taxonomy Term и текстовое поле. В первом окне выбор термина, во втором окне ввод значения. Может Field Collection подойдет или MultiField? Берут сомнение насчет дальнейшей поддержки данных модулей для D7. Может создать свои типы полей? Где лучше и понятнее об этом почитать (желательно с примерами)? Понимаю что напишут что на Drupal.org, но здесь спросил - может кто такое делал и как выкручивался из ситуации?
Второе двойное поле интереснее. Пока даже идей нет - может кто поделится. В принципе задача тривиальна - установить (тариф, плата, начисления и т.д.) с определенной даты. То есть в первом окне - дата, в втором окне - сумма. То есть сумма начислений будет действовать с установленной даты.
Пример: с 01.01.2020 г. - ставка 2000 руб., с 01.01.2021 г. - ставка 2100 руб.
Причем - обязательное условие просмотр истории начислений, что бы можно было зайти и посмотреть как менялись начисления по датам (начисления будут меняться 1-2 раза в год). Этакий аналог коммунальных начислений в платежках - тариф и дата с какого числа действует этот тариф с просмотром истории тарифов.
Как вообще такое лучше организовать? Думаю наверняка кто то уже такое делал? Может нет смысла заморачиваться с двойным полем а сделать Entity Referense? Но тогда в форме предусмотреть, что бы можно было править данный Entity как обычные данные в обычном field, что бы не переходит на другую сущность и добавление новых данных (число и тариф) было в данной форме?
P.S. - Немаловажная деталь - (второе "двойное поле" - число и тариф - таких значений много - реально больше 1000 шт.). Поэтому изначально и подумал о аналог Double Field.
Комментарии
А как-то покороче можно выразить?
Может paragraphs?
А поддержка D7 не вызывает сомнения?
Field Collection вполне нормальный модуль. К нему есть дополнительные модули.
По второму полю вообще не понятно, кто устанавливает\выбирает тариф? Это тариф на месяц или по дням? Какую сумму ставить с 02.01.2020го? Кто ежемесячно заполняет всей 1000 эти суммы по тарифам? ...
Прежде чем изобретать ваше поле, нужно определиться как это будет выглядеть в целом. Потом с типом материала "счет". Далее решить записывать (добавлять) ежемесячные счета в одну ноду или создавать для каждого пользователя отдельную ноду.
Выводить историю платежей можно через Views или Calendar
Просто несколько мыслей вслух:
Модуль Field Collection формально снят с сопровождения уже для V8, но при этом народ активно разрабатывает патч для его совместимости с V9. У меня на восьмерочном сайте он активно используется, и до недавнего времени я был уверен, что для перехода на девятку мне придется все перепахать на Paragraphs, а сейчас уже есть надежда, что удастся оставить как есть. При этом для новой разработки на 8/9 конечно лучше взять Paragraphs, имеющий однозначно лучшую поддержку на перспективу. Про семёрку ничего не знаю.
Это весьма нетривиально и не нужно. Всё, что Вам необходимо, уже есть, остаётся только выбрать лучший вариант.
Теоретически тут можно попробовать использовать встроенный механизм Revisions, все необходимые поля там уже есть. Не факт, что все получится красиво, но я бы по крайней мере подумал в эту сторону.
Тут важно понимать, что и у Field Collection, и у Paragraphs "под капотом" все равно отдельная сущность и Entity Reference, вопрос лишь в "обвязке".
Для этого есть модуль Inline Entity Form (IEF).
Вы не внимательно прочитали мое сообщение там же явно написано - (начисления будут меняться 1-2 раза в год) - соответственно - будет вводится один документ (node) на один объект один раз в год.
Таскать за собой всю revisions node ради одного поля - сомнительно, тем более что в ноде порядка 25 полей (представляю сколько tables будет создаваться в БД), а история изменений нужна по одном полю.
Paragraphs - к сожалению мне то же не подойдет. Сайт уже был сделан до меня и мне лишь нужно внести кое какие правки и весь сайт сделан на модуле Panels. Стыковать и Paragraphs и Panels - думаю то еще квест будет.
Да я так и хотел вначале сделать - но почему я спросил про отдельные поля а не Entity Referense в связке с Inline Entity Form. Реально будет создаваться (точнее загружаться из csv - руками такой объем не потянуть) порядка 2500 нод. И тогда у каждой ноды будет своей Entity Referense с датой и тарифом. То есть здесь получается что то типа подчиненного справочника. Есть нода, у нее подчиненный справочник Entity Referense. База будет разрастаться как снежный ком. Если другого решения не найду - так и сделаю. Если было так что данное поле с тарифом применялось ко всем нодам - ну как начисления за электричество к примеру, прописываешь один тариф - и ко всем нодам (счетам его применяешь) то вообще проблем бы не было. А у меня немного другая ситуация. У компании несколько тысяч клиентов на обслуживании и для каждой компании свой тариф - да еще что бы могли его поменять в течении года.