По следам переписки на форуме:
Предлагаю добавить дополнительный параметр в telephony.externalcall.finish чтобы при завершении звонка не менять ответственного за сущность
Предлагаю добавить дополнительный параметр в telephony.externalcall.finish чтобы при завершении звонка не менять ответственного за сущность
Нужен универсальный REST-метод для чтения (получения) истории CRM-сущности.
Например какой-нибудь crm.history.list с полями фильтра:
- ownerTypeId,
- ownerId,
- date (дата записи)
- entityField
- eventId
- assignedById
Например какой-нибудь crm.history.list с полями фильтра:
- ownerTypeId,
- ownerId,
- date (дата записи)
- entityField
- eventId
- assignedById
Хотелось бы иметь возможность через REST_API добавить свой источник сквозной аналитики с возможностью передачи туда Действий, Просмотров, Расходов
если в битриксе объединить 2 компании - то через REST api об этом никак не узнать.
При этом если выполнить запрос по crm.company.get по удаленному id то в ответ получим только {"error":"","error_description":"Not found"}
Если бы в этом ответе было еще одно поле merged_with id то счастье бы наступило немедленно в области синхронизации.
Я получу этот ид и повторю операцию объединения в базе 1С.
Если этого не сделать - то при следующем обмене 1С увидит "нового" не синхронизированного контрагента и выдавит его в битрикс. и опять придется бороться с дублями.
добавьте в crm.company.get и crm.contact.get поле с информацией о выжившем после объединения id
При этом если выполнить запрос по crm.company.get по удаленному id то в ответ получим только {"error":"","error_description":"Not found"}
Если бы в этом ответе было еще одно поле merged_with id то счастье бы наступило немедленно в области синхронизации.
Я получу этот ид и повторю операцию объединения в базе 1С.
Если этого не сделать - то при следующем обмене 1С увидит "нового" не синхронизированного контрагента и выдавит его в битрикс. и опять придется бороться с дублями.
добавьте в crm.company.get и crm.contact.get поле с информацией о выжившем после объединения id
Если посмотреть метод crm.contact.fields то можно увидеть пользовательские типы crm_company и crm_lead (и другие)
При этом существует стандартный тип "crm", с настройками SETTINGS.
В подолжении развитии идеи: предлагаю сломать в именовании типа обратную совместимость и заменить "crm_lead" на более универсальный "crm" с настройками.
При этом, так как поля содержат только один тип то содержать они будут так же идентификаторы (т.е. по составу данных обратная совместимость будет).
При этом существует стандартный тип "crm", с настройками SETTINGS.
В подолжении развитии идеи: предлагаю сломать в именовании типа обратную совместимость и заменить "crm_lead" на более универсальный "crm" с настройками.
При этом, так как поля содержат только один тип то содержать они будут так же идентификаторы (т.е. по составу данных обратная совместимость будет).
Ответил 
Антон Горбылев 14.09.2021 12:10:29
Антон Горбылев 14.09.2021 12:10:29
Нет возможности реализации из-за нарушения обратной совместимости.
Для основных сущностей (контакт, компания и т.п.) CRM наблюдаем следующую картину (на примере контакта показываю):
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.
В ответ на crm.*.fields для UF_* полей возвращается описание:
В нем вы видим важные параметры:
В нем мы НЕ видим:
В ответ на crm.*.userfield.list возвращается описание:
В нем мы видим важные параметры:
В нем мы НЕ видим:
Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
Т.е. дополнительный ключ items, который показывает что можно выбрать.
Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
- Есть метод 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 (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
Ответил
Антон Горбылев 14.09.2021 12:09:12
Антон Горбылев 14.09.2021 12:09:12
Выйдет в районе crm 21.1100.0
На данный момент в классе CBitrixRestEntity используется оператор self для обращений к методам внутри класса, что не удобно при наследовании класса.
Переработать класс c использованием позднего статического связывания.
Переработать класс c использованием позднего статического связывания.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
