"Artu" wrote:

Facet API Pretty Paths пробовали?

Пробовал, он вроде просто красивые адреса делает.

Высмотрел еще такой момент. Фасетные фильтры не могут работать с контекстными фильтрами, они не подставляют аргумент. и не воспринимают пути Views с аргументами, адрес получается такой "taxonomy/term/%" По этому и не работают.

Пока Хочу попробовать написать свой фильтр и попробовать подставить аргумент.

"ХулиGUN" wrote:

Тип материала "задача"(В Вашем случае это заявка) без дублирования...
Тип материала "решение задачи" с референс полем по типу "задача" (Можете как программно создавать, так и в ручную. Для более детальной отчётности можно добавлять дату)

Это все таки не совсем то. каждая заявка зарывается так или иначе.

"ХулиGUN" wrote:

Зачем? В чём сакральный смысл?

Есть заявки пользователей которые они каждый день делают и есть регулярные которые они делают скажем раз в день. Что-бы их каждый раз не делать нужен механизм что-бы они создавались автоматом. Копия нужна обязательно т.к. это по сути отдельная заявка и не должна быть связана с другими.

Задача проста. Есть тип нод пусть будет "событие". В данном типе есть поле где мы задем правила когда нужно ее повторить. Для этого подходит date_repeat_field из состава модуля date. По данным правилам нам нужно выполнять некий код. Скажем поставили периодичность раз в месяц вот каждый месяц нам нужно выполнить "наш код" но периоды для разных нод могут быть свои. Вот и вся задача.

date_repeat вроде должен подойти,но я до конца не понимаю как его правильно заюзать.

К такому способу и склоняюсь, но как-то не кошерно на мой взгляд.

Ну если вы посмотрите в начало публикации без date_repeat мне не обойтись. Мне как раз надо делать копию ноды по правилам который заданы в date_repet_field. Только вот как это реализовать я не пойму. date_repet_field - это множественное поле в котором будут перечислены все даты в зависимости от выбранных условий. Раз модуль их уже генерит я могу их использовать, но после использования мне нужно будет убирать те которые уже обработаны.

Пока пришел к такому способу по крону будет выполнятся некий скрипт который из нужной мне ноды будет получать даты из date repeat fields и делать свои дела. Так вот нужно из этого списка убрать уже обработанные даты что-бы при следующем запуске крона они не выполнялись. Пока склоняюсь только к изменению даты старта. Может есть более правильный путь?

У кого есть опыт работы с date_repeat? и date_repeat_field? не пойму как после обработки даты уменьшать список этих самых дат, что-бы больше их не обрабатывать?

"Chyvakoff" wrote:

У друпала свой обработчик сессий. А "другого скрипта" свой. Нужно привести их к одному виду.

Как привести? В сторонние скрипты я могу вносить изменения, но это не желательно. Все скрипты расположены на одном домене. У меня есть session_name используемый в сторонних скриптах. В одном из них я произвел связь просто прописав нужный session_name. Как это сделать в Drupal в идеале не затрагивая все остальные модули Drupal?

"Mnilionic" wrote:

Ноды обязательно дублировать? может просто привязывать одну и ту же ноду к разным датам?

Дублировать обязательно.

"ХулиGUN" wrote:

Единственное, что можно посоветовать это модули date & brain

Пока пытаюсь разобраться с date repeat

Раскрытые фильтры не нужны. Views создаем для вывода того индекса что создали в Search API. В моем случае это products и задаем адрес "продукция". После перехода по ссылке "продукция" будут выводится все материалы по индексу products в Search API. Так-же будут выводится фасетные фильтры (блоки) если они были настроены в Search API и добавлены в соответствующий регион. Все у нас готова страница продукции где эту самую продукцию можно фильтровать по доп параметрам.

Еще дополнение. Ели добавить display facet block, на нужную страницу, то на этой странице будут выводится фасетные фильтры, но главное условие display facet block должен быть выше фасетных фильтров в нужном регионе шаблона. Наткнулся на это совершенно случайно переместив блок выше. Как я понимаю данный способ был описан на данной странице https://drupal.org/node/2017007, но до конца я понять его не смог, теперь ясно.

"Artu" wrote:

Taxonomy menu ведет на представление, которое построено по индексу Search API?

Блок построен Views по обычной таксономии через стиль древовидного меню Views Dynatree
Страница термина таксономии переопределена с помощью модуля Taxonomy display

Спасибо за разъяснение, попробую и отпишусь потом.

Я конечно, еще попробую. Но вот этот запрос

"deb" wrote:

это как раз меняет inner join на left join, так что ваш хук тоже можно выкинуть.

Это меняет INNER на LEFT в отношениях, но не в фильтрах. Для строки:

"deb" wrote:

Так должны выводиться договоры или заявки?

Не корректно наверное выразился. Выводится должны все договоры, но по договору выводится сумма заявок которое считается из поля суммы в заявке. То есть мы выводим договоры, а сумму считаем по всем заявкам со статусом оплачено. Сами по себе заявки не выводятся а только участвуют в отборах и подсчете суммы.

"deb" wrote:

Не оч понятно. У 1го договора может быть много заявок? Нужно выводить договры у которых все заявки в статусе оплачено или хотя бы одна?

В заявке есть поле ссылка Entity Reference на договор. У договора может быть много заявок. Должны выводится все заявки со статусом оплачено. И все договоры да-же если у них нет заявок.

Проблема состояла в том что стандартный фильтр по выбранному термину делает INNER соединение с таблицей значений термина и из за этого пропадают значения у которых нет термина (NULL). Решением было или написать свой фильтр или изменить запрос hook-ом. Я пошел по второму варианту.

<%
function hook_views_query_alter(&$view, &$query) {
if ($view->name == 'my_view') {
$query->table_queue['Наше соединение']['join']->type = 'LEFT';
}
}
%>

Если есть более правильное решение буду рад услышать.

Может и не для этого, но было бы логично если можно было бы связывать фильтры Views в рамках одного представления или одного раздела сайта, для того что переходя со страницы на страницу данного раздела нам не приходилось заново устанавливать фильтры.

"iNFerNo" wrote:

нет

А какой подход к решению данной задачи посоветуете?

Спасибо, посмотрю

"whiesam" wrote:

Рулез?

Попробовал, но посыпались ошибки. Буду пробовать, просто хотелось бы одним модулем обойтись.

Еще вылезла такая проблемка с полем автодополнения. Если в наименование материала который выбирается через автодополнение поля Entity reference есть запятые то id выбранного материала не попадает в массив form_state.
при вызове функции Ajax обработчика. Подскажите есть ли решение для данной проблемы?

Еще мне не удалось настроить поиск по дополнительным поля сущьности при выводе списка через Views. Настройки есть галки для нужных полей ставлю а он по ним не ищет. Подскажите какие там тонкости в настройке есть.

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

И еще попутный вопрос: Как программно авторизовать пользователя не имея его пароля?
Нашел функцию user_authenticate но она требует пароль