Идеи пользователя
При создании шаблона отраслевого решения не сгружаются воронки смарт-процессов. Это очень важный функционал, так как с развитием смарт-процессов, множество процессов реализуется именно на них.
Интересно, что бизнес-процессы смарт-процессов сгружаются, но доступа к их редактированию нет, так как нет самих смартов.
В итоге приходится заново их выстраивать экспортируя и импортируя бизнес-процессы. Но в этом случае невозможно полноценно реализовать решение в маркете либо масштабировать на клиентов.
Интересно, что бизнес-процессы смарт-процессов сгружаются, но доступа к их редактированию нет, так как нет самих смартов.
В итоге приходится заново их выстраивать экспортируя и импортируя бизнес-процессы. Но в этом случае невозможно полноценно реализовать решение в маркете либо масштабировать на клиентов.
Ситуация:
При внесении изменений в бизнес-процесс во время тестирования, нет возможности откатиться на предыдущий вариант после сохранения. Приходится выдумывать альтернативные ветки для тестирования БП по различным условиям или сохранять блок действий чтобы была возможность ручного отката (замены), либо если совсем жёстко, то экспортировать версию процесса.
Также, при случайном удалении/изменении активити при написании процесса, невозможно нажать ctrl+z для того чтобы вернуть последнее действие. Приходится нажимать кнопку отмены и заново вносить изменения, а их могло появиться достаточно большое количество.
Предложение:
Добавить в конструктор систему контроля и выбора версий процесса по истории. Хотя бы до 10 версий. Для мелких ошибок, добавить возможность отмены последнего действия в редакторе (типа ctrl+z).
При внесении изменений в бизнес-процесс во время тестирования, нет возможности откатиться на предыдущий вариант после сохранения. Приходится выдумывать альтернативные ветки для тестирования БП по различным условиям или сохранять блок действий чтобы была возможность ручного отката (замены), либо если совсем жёстко, то экспортировать версию процесса.
Также, при случайном удалении/изменении активити при написании процесса, невозможно нажать ctrl+z для того чтобы вернуть последнее действие. Приходится нажимать кнопку отмены и заново вносить изменения, а их могло появиться достаточно большое количество.
Предложение:
Добавить в конструктор систему контроля и выбора версий процесса по истории. Хотя бы до 10 версий. Для мелких ошибок, добавить возможность отмены последнего действия в редакторе (типа ctrl+z).
Добрый день.
Предлагаю доработки "Бронирования" которые на мой взгляд привлекли к вам больше клиентов в виде стоматологий, салонов и других бизнесов.
1. Учёт графика работы.
При бронировании ресурсов нет учёта графика работы сотрудников. Но при этом функционал графика работы на портале есть и есть график отсутствий. Приходится лепить костыли.
2. Редактирование карточки на календаре бронирования.
Чтобы бронирование ресурсов было хоть каплю информативно приходится все данные пихать в название. Нет возможности выделения карточек цветами. При этом в календаре личном или компании половина функционала есть.
3. Календарь бронирования ресурсов
На календаре не возможно увидеть занятость всех сотрудников, либо колонками, либо строками. Чтобы взглянув на календарь можно было сразу увидеть, У Васи и Ивана свободны 14 часов. Сейчас это не возможно.
4. Обязательное заполнение поля бронирования ресурсов.
У всех полей есть функционал, чтобы поле было обязательно только на определённых стадиях, у этого нет. Хотелось бы чтобы был данный функционал.
5. Различные наборы условий выбора в бронировании.
Например, стоматология имеет 3 клиники по 10 врачей в каждой. Если создать 1 поле то администраторы будут видеть список из 30 врачей, 10 своих и 20 с других клиник. В этом хаосе невозможно найти свободное время.
А если делать отдельное поле для каждой клиники, то наступает полный ужас при попытке сделать любую автоматизацию в БП. приходится постоянно лепить проверки какое именно поле было заполнено, а так же заказчик звонит и говорит открываем 4 клинику и масштабировать это становится почти невозможно.
6. Баг при редактировании поля бронирование ресурсов.
Создаю поле, указываю 3-х сотрудников. Решаю добавить 4-го, нажимаю редактировать, а первых 3-х уже и нет и нужно снова их задавать. В общем поле не сохраняет своё состояние в поле сотрудники.
7. Нет синхронизации данных из лида в сделку при бронировании ресурсов.
Приходится мутить всё через БП, при этом ещё и сбрасывать запись в лиде, после передачи данных в сделку. Хотелось бы это видеть из коробки.
Мне кажется эти доработки позволили бы предлагать ваш продукт большему количеству бизнесов.
Предлагаю доработки "Бронирования" которые на мой взгляд привлекли к вам больше клиентов в виде стоматологий, салонов и других бизнесов.
1. Учёт графика работы.
При бронировании ресурсов нет учёта графика работы сотрудников. Но при этом функционал графика работы на портале есть и есть график отсутствий. Приходится лепить костыли.
2. Редактирование карточки на календаре бронирования.
Чтобы бронирование ресурсов было хоть каплю информативно приходится все данные пихать в название. Нет возможности выделения карточек цветами. При этом в календаре личном или компании половина функционала есть.
3. Календарь бронирования ресурсов
На календаре не возможно увидеть занятость всех сотрудников, либо колонками, либо строками. Чтобы взглянув на календарь можно было сразу увидеть, У Васи и Ивана свободны 14 часов. Сейчас это не возможно.
4. Обязательное заполнение поля бронирования ресурсов.
У всех полей есть функционал, чтобы поле было обязательно только на определённых стадиях, у этого нет. Хотелось бы чтобы был данный функционал.
5. Различные наборы условий выбора в бронировании.
Например, стоматология имеет 3 клиники по 10 врачей в каждой. Если создать 1 поле то администраторы будут видеть список из 30 врачей, 10 своих и 20 с других клиник. В этом хаосе невозможно найти свободное время.
А если делать отдельное поле для каждой клиники, то наступает полный ужас при попытке сделать любую автоматизацию в БП. приходится постоянно лепить проверки какое именно поле было заполнено, а так же заказчик звонит и говорит открываем 4 клинику и масштабировать это становится почти невозможно.
6. Баг при редактировании поля бронирование ресурсов.
Создаю поле, указываю 3-х сотрудников. Решаю добавить 4-го, нажимаю редактировать, а первых 3-х уже и нет и нужно снова их задавать. В общем поле не сохраняет своё состояние в поле сотрудники.
7. Нет синхронизации данных из лида в сделку при бронировании ресурсов.
Приходится мутить всё через БП, при этом ещё и сбрасывать запись в лиде, после передачи данных в сделку. Хотелось бы это видеть из коробки.
Мне кажется эти доработки позволили бы предлагать ваш продукт большему количеству бизнесов.
Сегодня у нас де-факто существует 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 из значений доступных операций (предпочтительнее).
Кнопка Запустить реагирует на нажатие ENTER на клавиатуре, только если один параметр в БП есть.
Как только второй добавить - никакой реакции. Нужно хватать обратно мышку, курсор искать, наводить и кликать на саму кнопку Запустить. Жутко неудобно.
Как только второй добавить - никакой реакции. Нужно хватать обратно мышку, курсор искать, наводить и кликать на саму кнопку Запустить. Жутко неудобно.
В корзине не отображаются уделенные Предложения. Либо вообще не попадают, либо не допилили кнопку выбора..
--------------
Заявка №
--------------
Заявка №
Зачем то при экспорте (например Счетов, Предложений итд) создается лишняя строчка в excel файле. Зачем это - непонятно. Жутко неудобно работать с файлом, сортировать и тд
---------------------------------------
Заявка в техподдержку №96554 висит..
---------------------------------------
Заявка в техподдержку №96554 висит..
Все привязывается кроме Предложений - недопил..
---------------------------------------
Заявка есть
---------------------------------------
Заявка есть
Поле типа "Привязка к элементам CRM" - "Счёт" в экспортированном excel-файле попросту не отображается - пусто.
--------------------------------
Заявка #174770
--------------------------------
Заявка #174770
Добрый день!
Можно ли сделать поле Бронирование ресурсов обязательным начиная с определенной стадии? Сейчас можно либо сделать обязательным всегда, либо необязательным.
Можно ли сделать поле Бронирование ресурсов обязательным начиная с определенной стадии? Сейчас можно либо сделать обязательным всегда, либо необязательным.
После последнего обновления были огорчены ряду неудачных изменений:
1. раньше сразу в ленте событий в лидах и сделках было видно прочитано письмо или нет, яркая желтая пометка была. Теперь же эту информацию можно увидеть только зайдя в письмо. Также из-за отсутствия этой желтой пометки в ленте событий все дела сливаются, сложно увидеть отправленные письма.
2. в ленте событий закрепить комментарий теперь можно в 2 шага, ранее только нажав на иголку-кнопку. Также комментарии теперь нельзя выделить цветом.
Верните, пжл, прежний функционал.
1. раньше сразу в ленте событий в лидах и сделках было видно прочитано письмо или нет, яркая желтая пометка была. Теперь же эту информацию можно увидеть только зайдя в письмо. Также из-за отсутствия этой желтой пометки в ленте событий все дела сливаются, сложно увидеть отправленные письма.
2. в ленте событий закрепить комментарий теперь можно в 2 шага, ранее только нажав на иголку-кнопку. Также комментарии теперь нельзя выделить цветом.
Верните, пжл, прежний функционал.
Параметры можно настроить, но окно для юзера, для их указания вручную не появляется, и алгоритм срабатывает даже если они как "обязательны"
Ввод таких параметров позволил бы:
- при перемещении на этап, требовать пароль от юзера (для Предложений особо актуально, так как нет прав на каждый этап)
- указывать ответственного в задачах
- изменять сроки чего угодно
- итд и тп
Ввод таких параметров позволил бы:
- при перемещении на этап, требовать пароль от юзера (для Предложений особо актуально, так как нет прав на каждый этап)
- указывать ответственного в задачах
- изменять сроки чего угодно
- итд и тп
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
