Я давно прошу. Недавно идею создавал, но так как бп пока не очень распространены - рейтинг вялый.Как в общем, практически по любому запросу по БП. К сожалению, технически сейчас разрабатывать типы данных для БП довольно неудобно. По-сути, штатно подразумевается только один способ - свойство инфоблока с обязательным наличием метода GetPublicEditHTML (иначе оно будет недоступно в БП), все штатные типы в БП, за исключением даты и текст/хтмл (эти два берутся из инфоблоков) - зашиты в код модуля и не поддаются кастомизации. Кроме того, не поддерживаются типы с настройками.
Вообще кастомные типы - одна из главных головных болей при работе с БП, возможность нормальных кастомных типов или сквозная поддержка типов ИБ с настройками просится давно, но дело пока стоит на месте.
Ага. Я тоже изначально обдумывал только одну задачу, исходил из неё, потом понял, что это не что-то специфическое, а вполне востребованное много где Давайте пообсуждаем, я не против. Хотелось бы иметь такой функционал очень. Пардон за шум в эфире, иногда по мере описания возникают новые идеи, а тут может и посоветует кто что
Хм. В принципе, если рассудить - ничего экзотического в таком функционале нет. Ситуация вполне типичная для той же веб-разработки. Заказали сайт, единственная продажа, затем - техподдержка. Оплата оной, данные по клиенту итп, всё то же самое, разве что потоки обычно разнятся на порядок, наверное. Поэтому зачастую можно обойтись без интеграции, клиенты являются пользователями, упрощена идентификациях их, возможно, вполне хватает функционала задач... Хотя если взять сам Битрикс - то у вас поток должен быть огого.
Господа из Битрикса, расскажите, как вы построили такую работу у себя? Начали ли вы пользоваться своей ЦРМ? Решали ли вопрос с интеграцией её с техподдержкой?
пс. также создавал идею по интеграции CRM и ТП. Плюс ранее люди просили пользовательские поля в ТП, что тоже помогло бы решить проблему.
Лид - заявка на подключение (веб-форма, телефон, бумажка, эл. почта). Этап лида может быть пропущен/объединён с подключением. Подключение - конвертация в "контакт"(?), генерация договора, внутренний тикет техникам, постановка в очередь, подключение, тестирование, включение услуг, закрытие тикета подключения, факт оплаты... - "сделка"? Заявка в ТП - (веб-форма, телефон, бумажное заявление, эл. почта), (авто)привязка к клиенту в ЦРМ по номеру договора, фио, телефон, паспорт, секретное слово, ящик. эл. почты... Отработка тикета, создание заявки техникам, постановка в очередь, выполнение, отбивка клиенту, закрытие... - ?
В итоге по каждому клиенту его подробные данные, история заявок ТП, история выполнения заявок, отчёты по выполнению, общему состоянию итп (репортер), интеграция со сторонними системами для получения и отображения допданных по клиенту (на откуп разработчику - истории платежей, состояния счёта, тарифные планы итп), разные интерфейсы и функции по разным категориям пользователей (контакт-центр, диспетчер техников, техники).
И т.п. Как-то так пока сумбурно наброски возникают.
CRM ориентирована на продажи в первую очередь, оно и понятно. Но есть и другие сценарии - предоставление услуг связи, например, дальнейшая ТП пользователей. Большая масса - физики, не "компании". Пока как-то не очень вижу CRM в этом направлении. Да, такими задачами обычно занимаются тикетные системы, но нужен функционал и CRM - заведение/импорт/хранение информации по клиентам, данных по договорам, подключенным услугам, рассылки, генерация договоров по шаблонам... и история обращений в ТП, автоназначение ответственных, SLA, итп. Т.е. своеобразная интеграция CRM и тикетной системы. Будет ли движение в таком направлении?
А, понял. Трабла с выводом заголовков свойств? Это да, отдельным массивом не передаётся описание свойств в шаблон. Сделайте result_modifier.php в шаблоне, и там дергайте описание свойств инфоблока через CIBlock::GetProperties и сохраняйте в arResult, чтобы у вас эти данные были доступны в шаблоне.
<?if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true)die();?>
<div class="news-list">
<?if($arParams["DISPLAY_TOP_PAGER"]):?>
<?=$arResult["NAV_STRING"]?><br />
<?endif;?>
<?foreach($arResult["ITEMS"] as $arItem):?>
/* здесь идёт цикл, в котором идёт отрисовка для для каждого элемента, и которую меняете на то, как вам нужно, строками таблицы, вырезано */
<?endforeach;?>
<?if($arParams["DISPLAY_BOTTOM_PAGER"]):?>
<br /><?=$arResult["NAV_STRING"]?>
<?endif;?>
</div>
Так вот. Очевидно вы отрисовываете таблицу внутри цикла всю, а там нужно отрисовывать только строки таблицы с элементами ИБ. А вывод шапки таблицы должен быть до цикла (foreach), закрытие таблицы - после его окончания (endforeach). Либо я не понимаю вашу задачу.
пытаюсь переделать шаблон компонента "новости", не получается вывести заголовки столбцов таблицы...точнее получается но они появляются ровно столько же раз скольо элементов в ИБ
Цитата
nukemonk пишет: Видимо шапку внутри цикла по элементам делате.
Цитата
Let4ik_Russia пишет: Если ее делать внутри цикла то она как раз таки и напечатается столько раз сколько будет итераций в цикле.
Так что в итоге-то? Сперва пишете, что шапка таблицы выводится по количеству элементов, я отвечаю, что шапку наверное в цикл по элементам завернули. Дальше ответ........
Например, функционал списков. Спецкомпонента для таких целей не помню, но реализуется он довольно элементарно - выборка (GetList) требуемых элементов и дальнейший их табличный вывод с помощью компонента main.interface.grid
Ещё вариант - использование компонентов списка новостей/каталога с кастомизированным в табличный вид шаблоном.
путь к ключам в BitrixVM в /etc/nginx/bx/conf/ssl.conf проще найти мануал в инете по настройке SSL с nginx (да и не только по ссл), чтобы просто понимать, как и что.
Да ну что вы накинулись на человека тоже. Вопрос вполне нормальный, по-моему. Да, так сложилось исторически, да, так удобней. Но и задуматься, имхо, тоже стоит. Тема воспринимается как некоторое однобокое восприятие, как ругаться, что ИЕ не соблюдает стандарты и в нём всё плохо с вёрсткой - так все горазды, а тут, на вопрос, почему не соблюдаются рекомендации - зацепились. Я не предлагаю переписывать всё, но задуматься-таки - стоит.
Посмотрел. Да, поддержка пока только частичная, принудительно проверяются уровень доступа с кодом больше "U", несмотря на наличие флага операции. Не знаю, зачем так сделано. В списках - вовсе в зачаточном состоянии, но возможно сработает запуск из списка элементов. Как вариант обхода (для докуметов (вебдава) в т.ч. - для новых полномочий выставить букву больше "U", но... с учётом реализации, я не уверен, что при назначении такой литеры на уровень доступа, у пользователя не появятся ещё какие-то дополнительные права на элемент. Надо проверять. И литеру ставить для доступа "V" (чтобы после U и перед W), чтобы минимизировать возможные последствия =(
Создайте новый уровень доступа для инфоблоков на основе "Чтения", включите в нём операцию "element_bizproc_start", выставьте его нужной группе пользователей для инфоблока списка.