Друзья, создал вот такую . Считаю, что полноценных бизнес-процессов без отладчика быть не может. Все кому надоело прогонять "вживую" БП при каждом изменении или переносе - голосуем.
UPD 12.10.2015 Сделал модуль свойства инфоблоков - привязка к сущностям CRM. Скачать можно
Была поставлена задача: в пользовательских списках сделать возможность выбирать компанию и товар из модуля CRM. Игорь Карпович писал про это , но такое решение не устраивало: на портале более 20000 товаров и более 20000 контрагентов (компаний). Для удобного поиска и выбора товара/компании необходимо использовать стандартный компонент (crm.entity.selector), который используется в модуле CRM.
Создаем пользовательские свойства для привязки к компании и товару. Создаем файлы usertype_company_crm.php и usertype_product_crm.php, инклудим их в init.php . Ознакомиться с кодом можно скачав файлы, я лишь остановлюсь на некоторых моментах.
Мое пользовательское свойство условно делится на 3 составляющих: отображение в карточке элемента, отображение в списке элементов и отображение в фильтре.
Итак по порядку
1. GetEditForm - функция, которая подключает всплывающее окошко на страницу редактирования (карточки) элемента в админке и в публичной части. Для записи и отправки свойства сделан скрытый инпут
Поясню: стояла задача не изменять работу скриптов компонента crm.entity.selector, поэтому при выборе товара во всплывающем окошке используется "обходной" вариант. Следующий фрагмент кода решает задачу сильного подтормаживания при поиске товаров. (именно товаров, т.к. с компаниями такого не наблюдалось). На ввод символов стоит обработчик события "keyup", что означает, что после каждого введенного символа происходит post запрос к компоненту crm.product.list, а именно к файлу list.ajax.php, который и осуществляет поиск по товарам. И если пользователь вводит слово "мотопомпа", то происходит 9 обращений (!) к этому фалу, что при количестве товаров более 20к выдает сильные тормоза (на скрине apache не загружен, в рабочие часы запросы могут исполнятся по 2-3 минуты!)
Для решения этой проблемы написал небольшую функцию, которая ставит таймер и выполняет отложенный поиск, что позволяет выполнять всего 1 запрос вместо нескольких и в разы сэкономить время. Поясню "тонкое место" при загрузке скрипта на страницу происходит отложенная смена обработчика события для поля ввода (у меня она установлена в 1500 миллисекунд). Сделано это потому, что форма выбора товара подгружается отложено и не сразу присутствует на странице.
<sc ript>
$(window).load(function() {
...
setTimeout(function(){
BX.unbindAll(BX('crm-crm-form-<?=str_replace('_','-',$strHTMLControlName['FORM_NAME'])?>-product-id-open_<?=$fieldIdentifier?>-search-input'));
BX.bind(BX('crm-crm-form-<?=str_replace('_','-',$strHTMLControlName['FORM_NAME'])?>-product-id-open_<?=$fieldIdentifier?>-search-input'), "keyup", function(event){ switchTimer();});
},1500);
function switchTimer() {
timeHandlerId=getCookie('timeHandlerId');
if(timeHandlerId!=0)
clearTimeout(timeHandlerId);
var crmID="crm-form-<?=str_replace('_','-',$strHTMLControlName['FORM_NAME'])?>-product-id-open";
timeHandlerId=setTimeout(function(){
CRM.SearchChange(crmID)
},2000);
document.cookie='timeHandlerId='+timeHandlerId;
}
// возвращает cookie с именем name, если есть, если нет, то undefined
function getCookie(name) {
var matches = document.cookie.match(new RegExp(
"(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
));
return matches ? decodeURIComponent(matches[1]) : undefined;
}
...
});
</sc ript>
Суть функции проста: при нажатии на клавишу создается отложенный вызов функции, id которой пишется в куку. Если пользователь не нажимает на клавишу в течении следующих 2х секунд, функция поиска выполняется, иначе создается новый отложенный вызов, а старый удаляется.
И последнее, что было необходимо - отображение списка товаров списком, а не таблицей. За это отвечает код
3. Теперь про фильтр (функция GetPublicFilterHTML). При отображении в фильтре используется crm.field.filter , тогда как не в фильтре подключается system.field.edit. За это отвечает флаг 'FILTER'=>'Y', компонента crm.entity.selector. Плюс при показе в фильтре изменяются некоторые стили.
Приведенный мною пример кода создает свойство для привязке к товару. Для того, чтобы создать привязку к компании необходимо в параметрах компонента crm.entity.selector указать
'ENTITY_TYPE' => 'COMPANY'
и всплывающее окошко будет отображать компании.
Порядок действий для подключения свойства привязка к товару в ваш проект (аналогично для свойства привязка к компании):
Скачиваем файл usertype_product_crm.php
Если не подключен JQuery - добавляем в файл строчку CJSCore::Init(‘jquery’); (спасибо Денис Диденко )
Спасибо за продукт Установил модуль Но есть одна проблема В админке -> Товарный каталог CRM: Элемент: Товар_2 - Редактирование все добавляется и редактируется нормально в форме редактирования и добавления Товар -> /crm/product/edit/11322/?list_section_id=584 значение не сохраняется подскажете что где поправить?
После обновления модуля "Универсальные списки" убрали возможность редактирования типов полей после их создания:
Updated: lists (15.0.2) [*]Исправлена ошибка проверки прав. [*]Теперь нельзя изменить тип поля после его добавления.
Согласитесь, это неудобно, когда список состоит из 32-х полей, а пользователю надо изменить некоторые типы полей. В принципе это даже удобно, когда корпортал небольшой, сотрудников немного. Но а когда их очень много и списков с полями тоже очень много - постоянно типы полей менять администратору? Это неприемлемо. Также неприемлемо допускать пользователя в административную часть, он ведь и напортачить там может и кнопочки разные нажимать (идеальную защиту от дурака еще никто не придумал).
Остается кастомизирование компонента lists.field.edit, но зачем? Ведь всего-то надо было при обновлении 15.0.2 оставить галочку в настройках модуля списков, позволяющую оставить функцию изменения типов полей после их создания, и кому надо было бы ее включил, вот и все
Думаю, что не я один над этим задумался, поэтому создал , призываю поддержать
Столкнулся со странной проблемой, решение которой к сожалению не нашел на просторах сети. При добавлении записей в справочник в hl инфоблоках не работает сортировка. Справочник представляет собой список всех возможных объемов и масс товара, а также его комплектности (килограммы, литры, шт итд). По мере импорта товаров необходимо добавлять записи в справочник, и вполне адекватным выглядит желание, чтобы все значения справочника располагались в порядке возрастания. Решаться это должно с помощью сортировки, которую я проставляю у вновь добавленных записей, т.е. если имеется запись с сортировкой 210 и запись с сортировкой 220, а мне необходимо, чтобы значение новой записи располагалось между ними, я присваиваю новой записи сортировку со значением 215, после чего запись успешно добавляется в конец моего справочника. Но ни в административной части редактирования справочника, ни в редактировании товара, ни в умном фильтре мое новое значение не располагается на нужном мне месте, а находится в конце списка, т.е. именно на том месте, где оно было добавлено. Может я что-то упускаю и не поставил какую-нибудь галку? Или же сортировка в hl инфоблоках работает как-то иначе и мне надо курить ману?
На текущий момент сортировка не используется нигде, кроме публичных компонент (исключение - умный фильтр) - поэтому Вы и наблюдаете такую картину. В обновлении highloadblock 14.5.1 выпустим сортировку по полю UF_SORT (при его наличии). В дальнейшем интерфейс свойства будет кардинально переработан и все эти вещи станут настраиваемыми. Конкретизировать сроки выхода, к сожалению, не могу.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Политика конфиденциальности 