Рейтинг: 0  
Новая
Предложил Колотов Петр 20.11.2020 09:42:55

Битрикс24 Мессенджер

Идея состоит в том чтобы реализовать похожий функционал, как недавно сделали в Яндексе - Я.Мессенджер. Главная особенность это зайдя на сайт и написав в чат у вас останутся контакты этого сайта в мессенджере Битрикс24 при условии, что у посетителя установлено приложение Битрикс24.Мессенджер либо есть регистрация на портале Битрикс24.
Рейтинг: 2.8902  
Новая
Предложил Горбушко Александр 20.11.2020 08:16:38

Типы связей задач

Еще одна идея из JIRA: При простановке связей у задач можно выбрать тип связи "Блокирует", "Связана", "Дубликат", "Клон". Последнее - специфичный сценарий, когда делаешь задачу на основе другой. Но вообще удобно потом хвосты искать по этим связям.
Рейтинг: 1.8902  
Новая
Предложил Горбушко Александр 20.11.2020 08:14:46

Перекрестные связи задач

В JIRA очень удобно реализована взаимная перелинковка задач: если линкуешь одну задачу (добавляешь связанную задачу) к другой, то у второй так же проставляется обратная ссылка.  
Рейтинг: 9.5608  
Новая
Предложил Николаев Андрей 19.10.2020 15:05:25

Добавить в crm.*.fields недостающую информацию

Для основных сущностей (контакт, компания и т.п.) CRM наблюдаем следующую картину (на примере контакта показываю):
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.

В ответ на crm.*.fields для UF_* полей возвращается описание:
{
   "UF_CRM_1603091288": {
      "type": "crm",
      "isRequired": false,
      "isReadOnly": false,
      "isImmutable": false,
      "isMultiple": false,
      "isDynamic": true,
      "title": "UF_CRM_1603091288",
      "listLabel": "Привяка к компаниям",
      "formLabel": "Привяка к компаниям",
      "filterLabel": "Привяка к компаниям"
   }
}


В нем вы видим важные параметры:
  • Технические характеристики (обязательность, множественность, динамичность и т.п.)
  • Его тип (привязка к CRM)
  • Отображаемые названия

В нем мы НЕ видим:
  • Параметров, которые необходимы для показа значения

В ответ на crm.*.userfield.list возвращается описание:
{
   "5": {
      "ID": "114",
      "ENTITY_ID": "CRM_CONTACT",
      "FIELD_NAME": "UF_CRM_1603091288",
      "USER_TYPE_ID": "crm",
      "XML_ID": null,
      "SORT": "100",
      "MULTIPLE": "N",
      "MANDATORY": "N",
      "SHOW_FILTER": "I",
      "SHOW_IN_LIST": "N",
      "EDIT_IN_LIST": "Y",
      "IS_SEARCHABLE": "N",
      "SETTINGS": {
         "LEAD": "N",
         "CONTACT": "N",
         "COMPANY": "Y",
         "DEAL": "N",
         "ORDER": "N"
      }
   }
}


В нем мы видим важные параметры:
  • Технические характеристики (обязательность, множественность, динамичность и т.п.)
  • Его тип (привязка к CRM)
  • Настройки (SETTINGS)

В нем мы НЕ видим:
  • Отображаемых названий

Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
{
   "UF_CRM_1603091201384": {
      "type": "enumeration",
      "isRequired": false,
      "isReadOnly": false,
      "isImmutable": false,
      "isMultiple": false,
      "isDynamic": true,
      "items": [
         {
            "ID": "26",
            "VALUE": "Значение 1"
         },
         {
            "ID": "27",
            "VALUE": "Значение 2"
         }
      ],
      "title": "UF_CRM_1603091201384",
      "listLabel": "Список из двух значений",
      "formLabel": "Список из двух значений",
      "filterLabel": "Список из двух значений"
   }
}

Т.е. дополнительный ключ items, который показывает что можно выбрать.


Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
Рейтинг: 0  
Новая
Предложил Карпов Константин 02.09.2020 12:12:56

Переход с 1c-bitrix на ИМ+CRM

Необходимо сделать дополнительный шаг - ограничение пользователей.
Сейчас, если в системе больше 12 пользователей, то сразу после активации купона все другие пользователи не могут зайти. А посмотреть, кто на лицензии из них, кто нет - можно только после конвертации.
Рейтинг: 1  
Новая
Предложил babayota 19.08.2020 12:22:22

Возможность изменения массива полей перед возвращением результата методе getMap

В ядре D7 было б не плохо внедрить обработчик "OnBeforGetMap", в котором можно было б добавлять свои зависимости после формировании результата но перед его возвратом в методе getMap. Для модуля report это панацея на сегодняшнее время)
Рейтинг: 2.6706  
Новая
Предложил Булатов Василий 01.08.2020 23:26:43

Доработка модуля почты

Открытый слайдер почты
1. Фильтр с ящиков по ответственному
2. Отображение писем со всех ящиков
3. Отображение ответственного
4. Быстрый доступ к созданию новых шаблонов
5. Отображение сущности
-----------------------------------------
Открытое письмо с почты
1. Быстрый доступ к шаблонам
2. Панель редактирования
3. Отображение сущности
4. Быстрое сохранение шаблона
Файлы:
UR_3VJ647_E.jpg (349.41 КБ)
u_G3ty_MASo.jpg (332.56 КБ)
Рейтинг: 16.7922  
Новая
Предложил Радион 27.05.2020 08:30:41

Доработка RPA Битрикс24

RPA - тема очень актуальная, но хотелось бы больше от этого инструмента. Ниже собрал идеи и замечания по данному функционалу:

1. Предложение. Синхронизация сущности RPA с такой же функцией "Бизнес-процесс со статусами". Если честно не совсем понятно, почему вы выбрали путь создания новой функции. По моему мнению, доработка интерфейса в вид RPA, функции "Бизнес-процесс со статусами" была бы логичней т.к. этим функционалом уже многие пользуются и он во многом превосходит возможности и гибкость нового.

2. Замечание. Многие поля в RPA невозможно передать в такие же полня в Списках. Например невозможно передать при создании элемента Списка поле из RPA вида "Привязка к элементам CRM", "Привязка к элементам инф. блоков" в аналогичные поля в Списках.

3. Предложение. Добавить возможность открытия того или иного бизнес-процесса из карточки сделки, лида, компании, группы... в виде дополнительных вкладок в этих карточках, если в процессе есть соответствующие поля обозначающие такую принадлежность (так как это сделано в списках).

4. Предложение. Возможность формирования документов процессах RPA по аналогии формирования документов в CRM. Часто требуется сформировать документ по шаблону на основе данных процесса, чтобы сотрудник вывел его на печать, подписал и отправил в какие либо внешние инстанции.

5. Предложение. Объединить RPA с разделом "Бизнес-процессы" или дать возможность работы с RPA из "Бизнес-процессы". Эти разделы настолько взаимосвязаны что приходится постоянно переходить между ними, чтобы оценить ситуацию по процессу.

6. Предложение. Добавить возможность группировать поля в карточке Бизнес-процесса, так как это реализовано в CRM. Часто полей очень много и это очень неудобно выводить их в одну группу.

7. Предложение. Добавить возможность запуска бизнес-процесса в RPA автоматически из стандартного последовательного бизнес процесса.

8. Предложение. Добавить составное поле. Например: если на стадии нужно выполнить задание типа "Прописать список работ с указанием нормочасов". Сейчас нет такого поля чтобы можно было построчно добавлять по 2 значения (Строка + Число). А такие поля очень часто нужны буквально везде, не только в RPA.
Рейтинг: 4.7804  
Новая
Предложил Чирков Александр 27.04.2020 03:16:00

Пользовательские поля задач использовать в роботах

Роботы в задачах не связаны с пользовательскими полями в задачах. (тариф Компания, облако)

Сейчас есть возможность создать пользовательское поле в задаче(например, число). У него будет код вида "UF_AUTO_######"
Роботы не видят и не могут использовать это поле ни по названию, ни по коду.
Даже просто уведомления с использованием такого поля вывести нельзя.

Где это можно было бы применять: есть некий список, в котором фиксируются (в том числе) факты выполнения задач по проекту: начало работ по задаче, завершение, время принятия.
ИД элементов этого списка занесены в пользовательское поле в задаче.
Без роботов приходится дублировать ИД элементов в теги (что ненадежно) или работать через исходящий вебхук (там пользовательские поля видно отлично) - но это громоздко, потому что придется обмениваться данными по каждому изменению в каждой задаче.
Рейтинг: 4.7804  
Новая
Предложил Трахтенберг Виталий 21.04.2020 17:25:54

WYSIWYG-редактор в бизнес-процессах

В редакторе бизнес-процессов в операциях "Отправить письмо" и им подобных есть поле ввода собственно сообщения. При этом HTML-код в нем понимается. Но вот сверстать там что-то возможно в принципе. И поле редактирования крошечное, и все идет кашей plain-text.

То есть задача отредактировать красивый шаблон письма превращается в проблему. Ее можно решить, редактируя в каком-то IDE, а потом скопировать сюда. Но если надо внести изменения - весь кардебалет начинается снова.

Настоятельная просьба - сделайте человеческий редактор, типа TinyMCE или чего-то вроде.

P.S. А также давно ожидающая заявка на возможность использовать в бизнес-процессах шаблоны писем!
Рейтинг: 0.8902  
Новая
Предложил Киндрук Дмитрий 16.04.2020 14:35:28

Бизнес-процессы -> Уведомления -> Сообщение в Открытую линию. Невозможно выбрать открытую линию по условию для отправки сообщения

Нужно иметь возможность отправлять сообщение в ОЛ в мессенджер, который можно выбрать по условию. Сейчас по умолчанию сообщения в ОЛ улетают в тот мессенджер, который в находится в нижней строчке списка карточки клиента. На скрине ниже - это будет телеграм
Файлы:
Рейтинг: 0.8902  
Новая
Предложил Киндрук Дмитрий 16.04.2020 12:11:55

Мобильное приложение. Отображение раздела "Мессенджер" в карточке клиента/компании

Очень нужно иметь возможность писать в мессенджер клиенту  из мобильного приложения - открывать диалог.
Кейс.
На СТО приходит клиент (ранее с клиентом уже было общение через ОЛ - viber), сдает авто на ремонт. В ходе ремонта клиенту нужно отправить фото состояния агрегатов/частей, которые необходимо заменить. Это делает мастер, который 95% времени находится в ремзоне. Сейчас начать диалог в мессенджере с клиентом можно только на рабочем месте на ПК и уже после этого диалог ОЛ становится доступным и в мобильном приложении.

Сюда же подойдет любой кейс, в котором сотрудникам, которые работают на выездах/удаленно, нужно держать связь с клиентами, которые используют мессенджеры.