Рейтинг: 0  
Новая
Предложил Николаев Андрей 20.10.2020 10:17:51

Унификация типов полей в rest

Если посмотреть метод crm.contact.fields то можно увидеть пользовательские типы crm_company и crm_lead (и другие)
При этом существует стандартный тип "crm", с настройками SETTINGS.

В подолжении развитии идеи: https://idea.1c-bitrix.ru/39468/ предлагаю сломать в именовании типа обратную совместимость и заменить "crm_lead" на более универсальный "crm" с настройками.
При этом, так как поля содержат только один тип то содержать они будут так же идентификаторы (т.е. по составу данных обратная совместимость будет).
Рейтинг: 7.6706  
Новая
Предложил Николаев Андрей 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 (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
Рейтинг: 2  
Новая
Предложил Николаев Андрей 07.09.2020 15:36:18

getLocalPath для .settings_extra.php

Коробка Битрикс24 чаще разрабатывается под средних и больших клиентов довольно хардово и следуя тенденции вынесения максимального количества доступных возможностей в local, было бы очень хорошо, если в local появилась возможность заменять settings_extra.

Почему это нужно сделать?
- Соблюдение принципы все в одном месте. Для init.php это уже работает, а настройки незаслуженно обделены. Получается что для перехода на новые рельсы нужно "работать в local/php_interface/", но при этом необходимо учитывать в репозитории "старый" /bitrix/.settings_extra.php. Если уж держать все в одном месте, то держать там именно все.
- Расширение возможности для коробки б24. Коробка б24 чаще всего разрабатывается "под ключ" для клиента, соответственно на выходе клиенту выдается по факту новый продукт с новыми возможностями. Однако в архитектуре продукта жестко зафиксировано, что создавать свои action могут только модули или файл .settings_extra. Регистрировать фиктивный модуль, который по факту подключается для каждого хита смысла нет, а другой способ - править файл в /bitrix/* директории, которая зачастую лежит в .gitignore полностью.
Рейтинг: 11.6706  
Новая
Предложил Николаев Андрей 25.08.2020 14:44:13

API: Темы битрикс24

При работе с коробочным битрикс24, клиент часто прости разработать собствественные темы на основании его корп.стилей. Темы размещаются в папке themes шаблона bitrix24. Так как каждый клиент хочет минимизировать боль при обновлении портала клиент не хочет выносить эту папку в local и менять ее содержимое в битриксе каждый раз при обновлении.

Суть идеи: в класс Bitrix\Intranet\Integration\Templates\Bitrix24\ThemePicker в методе getList предусмотреть событие, по которому можно будет дополнить стандартный список тем кастомными темами или переопределить существующие.
Какие use-case он должен закрыть:
- Добавление новой темы в список доступных тем
- Изменение списка доступных тем (удаление существующих)
Рейтинг: 1  
Новая
Предложил babayota 19.08.2020 12:22:22

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

В ядре D7 было б не плохо внедрить обработчик "OnBeforGetMap", в котором можно было б добавлять свои зависимости после формировании результата но перед его возвратом в методе getMap. Для модуля report это панацея на сегодняшнее время)
Рейтинг: 4  
Новая
Предложил Николаев Андрей 10.04.2019 13:09:54

JS core_condtree вынести в main

В модуле catalog есть красивое js-расширение core_condtree, на основании которого можно строить сложные условия для правил корзины (модуль sale) и т.п.
Он регистрируется как extension core_condtree и его классы напрямую никак не связаны с каталогом товаров.
То же и со стороны php - в модуле каталога лежит CGlobalCondCtrl, который из названия с самим каталогом никак не связан.

Предложение: вынести эти классы в Главный модуль (main) чтобы можно было использовать их в своих проектах, когда нет (или не требуется подключения) модуля Каталог
Рейтинг: 0  
Новая
Предложил Николай 22.03.2019 14:14:01

Событие в методы CompareFields сущностей CRM

Хотелось быть иметь  событие в методах CompareFields сущностей CRM. Например CCrmCompany::CompareFields, чтобы добавлять свою логику, например обработчик сверки пользовательских свойств.  
Рейтинг: 1  
Новая
Предложил Васильев Михаил 06.02.2019 10:42:58

Добавление событий для работы с пользователями

Добрый день,

хотелось бы в API иметь возможность работать с событиями onUserHired и onUserDismissed для приема пользователя на работу и увольнения соответственно.
Рейтинг: 2.7804  
Новая
Предложил Borisenko Valentin 05.12.2018 15:03:38

Генератор документов :: Пользовательские поля

Здравствуйте.

Думаю, будет полезным для всех - внедрение возможности создавать пользовательские поля в модуле "Генератор документов".
Рейтинг: 3.8902  
Новая
Предложил Анкудинов Евгений 30.11.2018 21:52:19

Откройте LEAD_ID на запись

Поступающие в Б24 Лиды я выгружаю по API к себе в ПО. Там происходит его обработка и там же я создаю "сделку" если пользоваться терминологией Б24.
Б24 универсальный инструмент и полностью под функционал своей отрасли его не заточишь. Поэтому хотелось бы обработку специфики вынести в отдельное ПО, а потом готовые данные снова загнать в Б24. И всё было бы в шоколаде )))
Откройте поле LEAD_ID в Контактах и компаниях для записи (сейчас только чтение) - тогда при создании этих сущностей можно будет пробрасывать связь с Лидом.
Хочу использовать функционал Б24 как можно более полно, чтобы аналитика выстраивалась от обращения до сделки и всего остального маркетинга.
Рейтинг: 6.5608  
Новая
Предложил Акулиничев Ярослав 12.09.2018 16:21:50

Отслеживание Веб-хуков

Добрый день!
Предложение заключается в опциональной (!) возможности отслеживать веб-хуки, которые не сработали.
Хотелось бы понимать, какие веб-хуки не "дошли" до сервера и, в следствии, не были обработаны.
Так же, хотелось бы получить возможность повторно отправлять не обработанные веб-хуки вручную, автоматически и программно

Схематично обрисую реализацию, которую я вижу:
1. Создается исходящий веб-хук, ставится галочка [ ] Отслеживать
2. После срабатывания события происходит запрос на сервер
3. ID веб-хука и запрос добавляются в некий список вебхуков
4. Сервер обратным (входящим) веб-хуком информирует о получении данных (напр. отсылает ID получившего веб-хука)
5а. Обработанный исходящий веб-хук удаляется из списка
5б. Нет ответа от сервера - оставить в списке / повторно отправить через N минут

Реализовать можно по разному, но суть остается той же - хочется понимать, что все запросы получены и обработаны.  
Рейтинг: 0  
Новая
Предложил Николай 11.04.2018 11:46:27

Возможность фильтровать проекты через API

При создании задачи, необходимо добавить событие при запросе списка проектов, для возможности задать свой фильтр.

Например, нужно убрать проекты из определенных тем. Ручная настройка параметров проектов не подходит.  
Рейтинг: 2.8902  
Новая
Предложил Николай 14.02.2018 16:50:29

Добавить в универсальные списки тип поля словарь

При создании полей списка добавить тип свойства словарь (highloadblock).  
Рейтинг: 1  
Новая
Предложил Николай 30.01.2018 12:05:03

Переработать класс CBitrixRestEntity c использованием позднего статического связывания

На данный момент в классе CBitrixRestEntity используется оператор self для обращений к методам внутри класса, что не удобно при наследовании класса.

Переработать класс  c использованием позднего статического связывания.
Рейтинг: 96.3884  
Новая
Предложил Николаев Андрей 04.01.2018 12:54:32

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

Очень часто возникает ситуация, когда обычных дел недостаточно (они не полны).
Например, нужно не только знать о том, был ли звонок совершен, но и с какой целью он был сделан.
Не только, узнать проведена ли встреча, но и том что обсуждалось на это встрече.

Сейчас это делается лишь при помощи комментария к событию, однако для каталогизации этого недостаточно.

Предлагается дать возможность создавать пользовательские поля для дел, с указанием к каким именно типам дел это относится.
Кейсы:
1) Допустим проектная компания, проводит встречи 4х типов: Пресейл, Продажа, Обсуждение работ и Закрытие. Необходимо получать статистику о том, сколько в среднем встреч тратится на клиента по конкретному типу. Так же, можно получить, в завимисоти от типа, текущую стадию проекта.
2) Предположим, у нас обучающая компания и необходимо фиксировать: сколько на встрече было сотрудников, как они оценили эту встречу, какие замечания были с их стороны, когда будет оплата. Да, это можно вести как сделку, но как учитывать, что по одному договору может быть несколько встреч, т.е. к 1 контракту может быть 5-6 выездов, с оценкой каждого выезда?

На данный момент, есть только возможность создать свой собственный тип события, однако это будет пустым дублированием возможностей, что создаст только путанницу для пользователей. А при условии "попадания дела" в отчеты по данным типам полей, можно будет строить отчеты совершенно другого уровня.