Идеи пользователя
В форме редактирования элемента CRM есть возможность настроить отображение поля Клиент (показывать контакта или нет, показывать компанию первой, показывать адрес, показывать реквизиты и т.д.). Нам нужно только поле с компанией.
К сожалению, при настройке быстрого создания карточки в канбане поле "Клиент" всегда показывается с контактом, реквизитами, телефоном, адресом и т.д. Это очень мешает. А изменить это нельзя. Можно только выбрать какие поля показывать, но не как их показывать.
По идее, параметры отображения поля должен совпадать с настройками отображения в обычной карточке элемента CRM, а не показываться "по дефолту".
Кроме того, должна быть возможность, если выбрана компания при выборе контакта показать сотрудников этой компании. Я не понимаю, зачем выводить вообще всех контактов - Елен, Александров и т.д.
Понятное дело, что мне нужна конкретная Елена, работающая в выбранной компани, а не случайная Елена из списка всех 2000 Елен в списке контактов нашего CRM. Либо возможность ввести новую Елену (если конкретной нет).
К сожалению, при настройке быстрого создания карточки в канбане поле "Клиент" всегда показывается с контактом, реквизитами, телефоном, адресом и т.д. Это очень мешает. А изменить это нельзя. Можно только выбрать какие поля показывать, но не как их показывать.
По идее, параметры отображения поля должен совпадать с настройками отображения в обычной карточке элемента CRM, а не показываться "по дефолту".
Кроме того, должна быть возможность, если выбрана компания при выборе контакта показать сотрудников этой компании. Я не понимаю, зачем выводить вообще всех контактов - Елен, Александров и т.д.
Понятное дело, что мне нужна конкретная Елена, работающая в выбранной компани, а не случайная Елена из списка всех 2000 Елен в списке контактов нашего CRM. Либо возможность ввести новую Елену (если конкретной нет).
Если настроить триггер на изменение поля, скажем, "Тип договора" - и при создании элемента смарт-процесса сразу его заполнить, то триггер не отработает. И элемент не передвинется на другую стадию
Нам нужно чтобы при создании элемента (договора), первоначально нужно было заполнить тип договора, а тогда при создании нового договора элемент сразу же перенесся на вторую стадию и в зависимости от выбранного типа договора, все поля элемента СП заполнились бы дефолтными для данного типа договора значениями, а также заполнились бы другие поля на основании выбранного клиента.
Сейчас же такое реализовать не получается. Т.е. нужно сначала создать элемент, а уже потом при следующем изменении - триггер срабатывает.
Нам нужно чтобы при создании элемента (договора), первоначально нужно было заполнить тип договора, а тогда при создании нового договора элемент сразу же перенесся на вторую стадию и в зависимости от выбранного типа договора, все поля элемента СП заполнились бы дефолтными для данного типа договора значениями, а также заполнились бы другие поля на основании выбранного клиента.
Сейчас же такое реализовать не получается. Т.е. нужно сначала создать элемент, а уже потом при следующем изменении - триггер срабатывает.
Хотелось бы иметь возможность в бизнес-процессах (как в CRM, так и в списках) простым действием получить/зарезервировать следующий номер определенного нумератора CRM для документа еще до генерации печатной формы этого документа.
Это нужно, например, для того, чтобы в смарт-процессе "Договоры с клиентами" получить следующий номер договора на одной из начальных стадий согласования договора и причем не только зафиксировать его в печатной форме (PDF-документе), но и сохранить его в поле TITLE элемента смарт-процесса — чтобы можно было его искать, вставлять в печатную форму, использовать в оповещениях и т.п.
Это нужно, например, для того, чтобы в смарт-процессе "Договоры с клиентами" получить следующий номер договора на одной из начальных стадий согласования договора и причем не только зафиксировать его в печатной форме (PDF-документе), но и сохранить его в поле TITLE элемента смарт-процесса — чтобы можно было его искать, вставлять в печатную форму, использовать в оповещениях и т.п.
Прошу сделать возможным при указании физических адресов объектов создавать страницы данных объектов на которых будет собрана информация в каких сделках данный объект участвовал и какие задачи относятся к данному объекту.
Также не плохо было бы видеть информацию на инерактивной карте (за основу можно взять яндекс карту или любую другую) по каким объектам созданы сделки и задачи с привязанными физическими адресами.
Также не плохо было бы видеть информацию на инерактивной карте (за основу можно взять яндекс карту или любую другую) по каким объектам созданы сделки и задачи с привязанными физическими адресами.
Сегодня у нас де-факто существует 2 версии API: старый CCrm* с событиями и новый подход с фабрикой и операциями. Я не являюсь сторонником старого подхода, однако в новом подходе партнеры разрабатывающие тиражные приложения получили существенный недостаток - их лишили возможности динамически подписываться на события.
В новом подходе архитектурно у нас нет событий в их текущем виде и для того чтобы добавить свое поведение в какой-нибудь СП необходимо перекрывать фабрику этого СП и добавлять Action, что в свою очередь пораждает проблемы в тиражном приложении: невозможно поставить 2 тиражных приложения каждое из которых перекрывает одну и ту же фабрику.
Предлагаю свое компромисное решение: мы будем использовать событие, которое будет добавлять Action's к Operation.
Мне совершенно не нравится идея когда мы будем тащить события для обратной совместимости как это было со сделками, однако сам механизм событий показал себя вполне хорошо.
Предлагаю расширить методы получения операций `get*Operation` в `Bitrix\Crm\Service\Factory` чем-то вроде такого:
Таким образом можно получить следующие преимущества:
1. Возможность динамического расширения операций без кастомизации фабрик.
2. Как следствие пункта 1 - возможность использовать это в модулях для маркетплейса
Почему в `OnBuildOperation` не передается операция?
Сама операция является высокоуровневым действием и ее настройки, а так же опции должны конфигурироваться вызываемой строной, в то время как прямая передача ее в событие позволит значительно менять поведение системы, что сильно усложнит отладку.
К тому же - событие является глобальным, а значит что для определения нужного смарт-процесса в таком случае необходимо все равно было бы тащить туда данные текущей фабрики.
Для определения типа операции предлагается использовать название класса операции или возможно Enum из значений доступных операций (предпочтительнее).
В новом подходе архитектурно у нас нет событий в их текущем виде и для того чтобы добавить свое поведение в какой-нибудь СП необходимо перекрывать фабрику этого СП и добавлять Action, что в свою очередь пораждает проблемы в тиражном приложении: невозможно поставить 2 тиражных приложения каждое из которых перекрывает одну и ту же фабрику.
Предлагаю свое компромисное решение: мы будем использовать событие, которое будет добавлять Action's к Operation.
Мне совершенно не нравится идея когда мы будем тащить события для обратной совместимости как это было со сделками, однако сам механизм событий показал себя вполне хорошо.
Предлагаю расширить методы получения операций `get*Operation` в `Bitrix\Crm\Service\Factory` чем-то вроде такого:
public function get*Operation(Item $item, Context $context = null): Operation\Add
{
$operation = new Operation\Add($item, $this->getOperationSettings($context), $this->getFieldsCollection());
// ....
$event = new Event("crm", "OnBuildOperation", [
'factory' => $this,
'actionClass' => get_class($operation)
]);
$event->send();
if ($event->getResults())
{
foreach($event->getResults() as $eventResult)
{
if ( $eventResult->getResultType() !== EventResult::SUCCESS )
{
continue;
}
$eventParameters = $eventResult->getParameters();
if ( isset($eventParameters['ACTIONS']) && is_array($eventParameters['ACTIONS']) )
{
foreach ($eventParameters['ACTIONS'] as $action)
{
if ( !is_object($action['OBJ']) || !($action['OBJ'] instanceof Operation\Action) )
{
continue;
}
$operation->addAction(
$action['PLACE'],
$action['OBJECT'],
);
}
}
}
}
return $operation;
} |
Таким образом можно получить следующие преимущества:
1. Возможность динамического расширения операций без кастомизации фабрик.
2. Как следствие пункта 1 - возможность использовать это в модулях для маркетплейса
Почему в `OnBuildOperation` не передается операция?
Сама операция является высокоуровневым действием и ее настройки, а так же опции должны конфигурироваться вызываемой строной, в то время как прямая передача ее в событие позволит значительно менять поведение системы, что сильно усложнит отладку.
К тому же - событие является глобальным, а значит что для определения нужного смарт-процесса в таком случае необходимо все равно было бы тащить туда данные текущей фабрики.
Для определения типа операции предлагается использовать название класса операции или возможно Enum из значений доступных операций (предпочтительнее).
Возможность создавать отдельные меню в основном меню портала , и группировать (как "Совместная работа") администратором для каждого подразделения в отдельности
Было бы очень хорошо, сделал одно для продавьцов, второе для закупщиков, или третье для логистов. Новый логист добавляется на портал, и видит сразу адаптированное под него главное меню.
Было бы очень хорошо, сделал одно для продавьцов, второе для закупщиков, или третье для логистов. Новый логист добавляется на портал, и видит сразу адаптированное под него главное меню.
Прошу добавить возможность настраивать отображение столбцов на виде "Канбан" и "Мой план" в соответствии с выбраной группой, т.е. необходимо в некоторых группах скрывать не используемые столбцы, чтобы для определенной группы отображались только некоторые столбцы, а не все сразу.
Также не плохо было чтобы столбцы которые не помещаются на экране могли сворачиваться, к приверу в боковую панель и отображать кол-во новых и те что в работе задач, а также непрочитанных коментариев по ним.
Также не плохо было чтобы столбцы которые не помещаются на экране могли сворачиваться, к приверу в боковую панель и отображать кол-во новых и те что в работе задач, а также непрочитанных коментариев по ним.
Прошу добавить возможность вставки в текстовый редактор предустановленых информационных блоков типа Информация, Важно, Предупреждение разных цветов по типу блоку цитаты, также не помешает иметь возможность вставки редактируемого блока в котором можно изметить цвет рамки, цвет заливки и тему блока.
Примеры таких блоков приведены на скриншотах в прикрепленных файлах.
Примеры таких блоков приведены на скриншотах в прикрепленных файлах.
Здравствуйте. Есть предложение которое нравится мне и моей команде. По поводу создания настоек группы, канала как допустим в телеграмме(такое же в ВК, Вайбере и ватсапе). Благодарен за понимание. И хотелось бы услышать ответ.
Необходима возможность в добавлении связи (как в "Задачах») событий в календаре с друг дружками. Т.е. вот прошло событие или только намечается "Встреча 1", и создаётся новое событие "Встреча 2" и в ней указывается "Встреча 1" и можно быстро к ней перейти что бы посмотреть список участников или описание и другие данные. Естественно связь один ко многим, что бы к событию можно было добавить несколько других событий, а в добавляемых событиях было отображено с кем они связаны.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
