Сегодня у нас де-факто существует 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 из значений доступных операций (предпочтительнее).
В визуальном редакторе есть область для добавления изображения. Чтобы добавить изображение через визуальный редактор, нужно кликнуть на надпись drag&drop. Предлагаю увеличить область клика, чтобы можно было не целиться в надпись, а достаточно было кликать на прямоугольную область, в которой должно размещаться изображение. А область эта очень большая. Это значительно сократит время и силы при наполнении сайта.
Сейчас на каждом сообщении есть доступный перечень реакций и это очень круто.
Однако комплект реакций не полный.
Много клиентов хотят расширить его. Да чего греха таить - мы и сами все больше пользуемся Битрикс24 и поняли что нам жизненно необходимо использовать реакции: огонь, куча г.., рвота и феерверк.
Пожалуйста - дайте возможность увеличивать реакции для портала, ну или хотя бы расширьте их сами
Однако комплект реакций не полный.
Много клиентов хотят расширить его. Да чего греха таить - мы и сами все больше пользуемся Битрикс24 и поняли что нам жизненно необходимо использовать реакции: огонь, куча г.., рвота и феерверк.
Пожалуйста - дайте возможность увеличивать реакции для портала, ну или хотя бы расширьте их сами
Напишу коротко: было бы круто упростить процесс перехода с облака на коробку если это возможно по следующему сценарию: в каждом облачном портале есть раздел куда вводится купон коробки, купон проверяется модератором 1С-Битрикс на корректность и после этого в этом разделе появляется кнопка "Сделать бэкап", которая формирует бэкап в удобное для клиента время, а не только в рабочее время техподдержки.
Либо как альтернативный вариант: предлагать платную услугу по индивидуальной подготовке бэкапа в удобное для клиента время, многие клиенты готовы будут заплатить чтобы не оставлять компанию без Битрикс24 минимум на 1 рабочий день.
Либо как альтернативный вариант: предлагать платную услугу по индивидуальной подготовке бэкапа в удобное для клиента время, многие клиенты готовы будут заплатить чтобы не оставлять компанию без Битрикс24 минимум на 1 рабочий день.
Кто-то работает с поставщиками, кто-то с клиентами, кто-то с партнерами (маркетологи, логисты, и т.д.). Было бы логично разделять доступ сотрудникам портала - по типу контактов или компаний. Например, тип компаний "Поставщик" будут видеть только сотрудники отдела Закупа, и другие, кому необходим доступ.
Каждый новенький пользователь портала видит в своем чате "Поддержку Битрикс24" (коробка). Если даже он не перепутает её с локальной поддержкой портала, и сознательно начнет писать вопросы (90% из которых ответ ему подскажет его интегратор или сосед по кабинету), разве это будет эффективной поддержкой со стороны Битрикс24? Может быть поэтому их операторы и перегружены? Я не предлагаю вообще запретить пользователям писать в "главную" поддержку. Я предлагаю - при помощи прав доступа ОГРАНИЧИТЬ некоторые группы пользователей, чтобы они вообще не видели этот функционал в своем чате.
Битрикс сам работал на модуле Тех. Поддержка (который поставляется в релизе) - с тикетами, оценками, и главное - с возможностью оказывать поддержку как авторизованным сотрудникам портала, так и пользователям со стороны (через эл. почту).
Зная, что Битрикс работает с этим модулем, мы организовали такую же поддержку пользователей и у клиента на портале (более 100 человек).
Теперь Битрикс переходит с Тех.Поддержки на Открытые линии, НО!!! Теперь наши авторизованные пользователи остаются за бортом(( Ведь Открытые линии не поддерживает авторизованных пользователей, даже в онлайн-чат они написать не могут(
Получается. модуль Открытые линии ЧУТЬ ЧУТЬ не дотягивает до организации тех поддержки на портале, а старый модуль Тех. Поддержка, как уже всем понятно, не только морально устарел, но и откровенно заброшен разработчиком.
Битрикс, дайте нам пожалуйста использовать Открытые линии для организации тех поддержки пользователей портала. Для этого нужно к открытой линии подключить авторизованных пользователей, ну, и желательно сделать возможной подключить эл почту (сейчас есть серьезные ограничения).
Зная, что Битрикс работает с этим модулем, мы организовали такую же поддержку пользователей и у клиента на портале (более 100 человек).
Теперь Битрикс переходит с Тех.Поддержки на Открытые линии, НО!!! Теперь наши авторизованные пользователи остаются за бортом(( Ведь Открытые линии не поддерживает авторизованных пользователей, даже в онлайн-чат они написать не могут(
Получается. модуль Открытые линии ЧУТЬ ЧУТЬ не дотягивает до организации тех поддержки на портале, а старый модуль Тех. Поддержка, как уже всем понятно, не только морально устарел, но и откровенно заброшен разработчиком.
Битрикс, дайте нам пожалуйста использовать Открытые линии для организации тех поддержки пользователей портала. Для этого нужно к открытой линии подключить авторизованных пользователей, ну, и желательно сделать возможной подключить эл почту (сейчас есть серьезные ограничения).
Выбирая "возможности", т.е. функционал группы, если вы хотите в группе видеть только Живую ленту (т.е. ленту сообщений), то у вас это не получится. У вас в любом случае будет два пункта меню: Основное и Сообщения, которые будут делать одно и то же. Если вы отключите Сообщения, то пункт Основное (дальше интересно) не исчезнет, но перестанет работать (будет неактивный). Выглядит нелепо. Я понимаю, что есть способы это самостоятельно это исправить, но хочется это видеть в стандартном релизе.
Скрин прилагаю.
Скрин прилагаю.
Эта галочка влияет сразу на два разных поведения:
1. Включает/выключает возможность ЗАПУСТИТЬ этот процесс из Живой ленты.
2. Включает/выключает ОТОБРАЖЕНИЕ в Живой ленте заданий данного БП.
А если мне первое не нужно, а второе нужно - что делать?
Предлагаю сделать две настройки, чтобы каждая контролировала свою часть.
1. Включает/выключает возможность ЗАПУСТИТЬ этот процесс из Живой ленты.
2. Включает/выключает ОТОБРАЖЕНИЕ в Живой ленте заданий данного БП.
А если мне первое не нужно, а второе нужно - что делать?
Предлагаю сделать две настройки, чтобы каждая контролировала свою часть.
Мы переехали на коробку, но некоторые сотрудники долгое время заходят на старый портал. Невозможно везде прописать у сотрудников новую ссылку, и перенастроить всем мобильное приложение. Если мы уже переехали в коробку, почему мы не можем удалить из вашего облака наши старые данные? Какой смысл держать в облаке устаревшие данные? Почему мы сами (взрослые люди) не можем принять решение об их удалении? У нас проблема в том, что в течении дня обязательно кто-нибудь зайдет на старый портал - как можно дождаться 50 дней до его удаления? Это же просто невозможно. Замкнутый круг какой-то. Когда мы добьемся, чтобы люди окончательно перестали заходить на старый, нам его уже и удалять то не нужно будет 
Мне кажется, что было бы очень логично, если email-трекер ящика компании был не cтолько частью CRM, сколько частью открытых линий. (Хотя в CRM его можно оставить)
Во-первых, это логично с точки зрения унификации входящих каналов коммуникаций компании. Email должен быть таким же каналом, как и чат или телеграм.
Во-вторых, сейчас email-трекер CRM позволяет добавить только 1 ящик компании, в то время, как у компании может быть множество подразделений, отделов, ящиков, заведенных для определенных акций, продуктов и вымышленных сотрудников (вроде Платона Щукина). На каждый такой email хотелось бы иметь свою открытую линию, со своими правилами, ответственными.
В результате получения письма должен родиться лид и его номер хотелось бы иметь возможность отправить в ответе (особенно, если он появился в нерабочее время).
И жаль, что нельзя выбрать целый отдел или группу, кому будет доступен сгенерированный лид (очередь), а не конкретных пользователей.
P.S. Обновите список категорий в данной форме. В нем нет "Открытых линий"
Во-первых, это логично с точки зрения унификации входящих каналов коммуникаций компании. Email должен быть таким же каналом, как и чат или телеграм.
Во-вторых, сейчас email-трекер CRM позволяет добавить только 1 ящик компании, в то время, как у компании может быть множество подразделений, отделов, ящиков, заведенных для определенных акций, продуктов и вымышленных сотрудников (вроде Платона Щукина). На каждый такой email хотелось бы иметь свою открытую линию, со своими правилами, ответственными.
В результате получения письма должен родиться лид и его номер хотелось бы иметь возможность отправить в ответе (особенно, если он появился в нерабочее время).
И жаль, что нельзя выбрать целый отдел или группу, кому будет доступен сгенерированный лид (очередь), а не конкретных пользователей.
P.S. Обновите список категорий в данной форме. В нем нет "Открытых линий"
Реальный кейс - клиент захотел возможность дублирования фактического адреса в юридичнский и почтовый адреса. Как известно у битрикса сущность адреса (\Bitrix\Crm\AddressTable). Предвкушая радость работы с ORM мы выкатили заказчику 0.5 часа.
А дальше нас ждал бооольшой облом - Вы используете \Bitrix\Crm\AddressTable (по факту как вы называете ORM) и не используете ее методов!! Точнее - вы написали функцию upsert, которая напрямую сохраняет адрес в базе данных. Коллеги, если вы сами нарушаете свои же принципы, то как вы можете принимать экзамены, если у самих все "хорошо" ???
Уберите этот upsert или хотя бы дайте на него события!
А дальше нас ждал бооольшой облом - Вы используете \Bitrix\Crm\AddressTable (по факту как вы называете ORM) и не используете ее методов!! Точнее - вы написали функцию upsert, которая напрямую сохраняет адрес в базе данных. Коллеги, если вы сами нарушаете свои же принципы, то как вы можете принимать экзамены, если у самих все "хорошо" ???
Уберите этот upsert или хотя бы дайте на него события!
В компании уже 2-й год используется корпоративный портал Битрикс-24 (коробка). На студентов, приходящих на практику, не заводятся учетные записи Битрикса (поскольку это неосновные сотрудники компании). Поэтому они работают со мной через бесплатное "облако", приходится им ставить там задачи. Но как же часто приходится сталкиваться с ситуацией, когда уже сформулированная задача на основном портале (коробка) вынуждена "копипаститься" на "облако". Неужели нельзя предусмотреть синхронизацию с "облаком" по выбору владельца задачи? Надеюсь идея многим понравится, поскольку лето - это пора студенческой практики. 
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
