Создал список, его нужно синхронизировать с внешней базой (под Yii2 работает Back). В списке добавил поля ORIGIN_ID и ORIGINATOR_ID, чтобы было похоже на объекты CRM Как получить элемент из CRM по этому идентификатору? Насколько понял из описания здесь фильтр по собственным полям невозможен?
Похоже, поиск по свойствам (полям, созданным самостоятельно) не предусмотрен
Выход по этому вопросу - генерировать Наименование с данными из значений ORIGIN_ID и ORIGINATOR_ID и искать по нему. типа такого
Код
'NAME'=>$ORIGIN_ID."@".self::originator_id,
Только так тоже не работает При, уверен, корректном запросе - проверял в СУБД {"TYPE":"lists","ID":"98","CODE":"materUser","ACTIVE":"Y","CHECK_PERMISSIONS":"Y","SITE_ID":"s1"} - это в $filter метод \CIBlock::getList($order, $filter); возвращает ложь и, соответственно
Виталий Овчинников написал: Выход по этому вопросу - генерировать Наименование с данными из значений ORIGIN_ID и ORIGINATOR_ID и искать по нему.типа такогоКод'NAME'=>$ORIGIN_ID."@".self::originator_id,
какаяч то ересь - зачем это если есть возможность фильтрации?
Цитата
FILTER Фильтрация элементов. Объект с списком полей и значений. Для фильтрации доступны почти все поля из фильтра CIBlockElement::GetList. Так же есть возможность использовать полнотекстовый поиск. Для этого Нужно использовать поле SEARCHABLE_CONTENT с префиксом "*";
Роман Семёнов написал: нет возможен - и пример есть и параметр описан в документации
читаем внимательно и получаем:
Скрытый текст
Фильтрация элементов. Объект с списком полей и значений. Для фильтрации доступны почти все поля из фильтра CIBlockElement::GetList.
Если не полениться и ткнуть ссылку, то "неожиданно" выясняется, что фильтрация по собственным полям и не возможна!
Ну, а если глянуть в соответствующий метод, то видим, что фильтры по своим данным (они в отдельной таблице) отсутствуют. В принципе, обращения к этой таблице нет. От слова совсем.
Цитата
Роман Семёнов написал: какаяч то ересь - зачем это если есть возможность фильтрации?
Виталий Овчинников написал: "ERROR_IBLOCK_NOT_FOUND" "Iblock not found"в коде же этого метода чёрт ногу сломит
передаете несуществующий id инфоблока
Я читать умею . Инфоблок - публичное название и, на самом деле, речь идет о таблице b_iblock, верно? Так вот, соответствующая запись в этой таблице присутствует как по ID, так и по коду. И SQL-ным запросом прекрасно получается.
Виталий Овчинников написал: Ну, а если глянуть в соответствующий метод, то видим, что фильтры по своим данным (они в отдельной таблице) отсутствуют. В принципе, обращения к этой таблице нет. От слова совсем
Так вы точнее ставьте вопрос. Из чего там следует, что поля вообще в другой таблице?
Цитата
Виталий Овчинников написал: Похоже, поиск по свойствам (полям, созданным самостоятельно) не предусмотрен
Предусмотрен, если они добавлены согласно документации. Постоянно фильтрую по своим полям с 2009 года ни разу не столкнулся с проблемами.
Цитата
Виталий Овчинников написал: Так вот, соответствующая запись в этой таблице присутствует как по ID, так и по коду
Т.е. в SQL вы обращаетесь только по ИД, а через апи чуть более подробный фильтр. что как бы намекает на то, где искать проблему. Вы в точности повторили фильтр?
Уточните ситуацию. Что это за свои поля, которые хранятся в другой таблице. Что за таблица и почему они там хранятся?
Пальцем в небо (может вы просто документацию не внимательно прочитали): вы знаете что пользовательским свойствам при использовании их в фильтре надо добавлять префикс "PROPERTY_" ? т.е. например PROPERTY_ORIGINATOR_ID
Александр Воробьев написал: Предусмотрен, если они добавлены согласно документации.Постоянно фильтрую по своим полям с 2009 года ни разу не столкнулся с проблемами.
Александр, а можно рабочий пример фильтра?
Предположу, что под "добавлены согласно документации" подразумевается изменение модели объекта. Понятно, конечно, что так можно. Я же спросил про пользовательскую историю без изменения кода или структуры базы совсем.
Цитата
Александр Воробьев написал: Так вы точнее ставьте вопрос. Из чего там следует, что поля вообще в другой таблице?
Оно и не должно следовать. Вы с Романом утверждаете, что поиск по своим полям ведется. Документация и код rest api говорят об обратном. Повторюсь, по-умолчанию я предпочел бы пользоваться пользовательским интерфейсом и документированными методами. А они не подразумевают фильтрации по полям списка кроме Наименования
Виталий Овчинников написал: Так вот, соответствующая запись в этой таблице присутствует как по ID, так и по коду
Т.е. в SQL вы обращаетесь только по ИД, а через апи чуть более подробный фильтр. что как бы намекает на то, где искать проблему. Вы в точности повторили фильтр?
Вот фильтр, который возвращает false {"TYPE":"lists","ID":"98","CODE":"materUser","ACTIVE":"Y","CHECK_PERMISSIONS":"Y","SITE_ID":"s1"}
Вот запрос, который возвращает соответствующую запись SELECT * FR OM `b_iblock` WHERE `ID` = 98 AND `IBLOCK_TYPE_ID` LIKE 'lists' AND `LID` LIKE 's1' AND `CODE` LIKE 'materUser' AND `ACTIVE` LIKE 'Y'
Какой запрос генерирует и отправляет фреймворк мне не известно. Ну и не должно быть известно яжюзер.