Универсальные списки, типы данных полей
Это как издевательство над пользователями выгладит, если честно.
Заходим в универсальные списки, создаем поля........
........ и обнаруживаем, что там нет поля с типом данных "radio" (переключатель)
И более того, привязка к картам там Яндекс, а не Гугл, как в пользовательских полях. И многое другое....
И как жить после этого? т.е. по вашему я создаю элемент списка и ввожу там адрес с привязкой в Яндексе, а потом я работаю со Сделкой, а у меня там адрес но уже с привязкой к гуглу?
Надо как-то привести к общему знаменателю типы данных полей в Универсальных списках и для CRM. Все-таки мы их завязываем между собой и ссылаемся в БП нужно чтобы они совпадали.
ООООчень надо!!!! Срочно!!!
Заходим в универсальные списки, создаем поля........
........ и обнаруживаем, что там нет поля с типом данных "radio" (переключатель)
И более того, привязка к картам там Яндекс, а не Гугл, как в пользовательских полях. И многое другое....
И как жить после этого? т.е. по вашему я создаю элемент списка и ввожу там адрес с привязкой в Яндексе, а потом я работаю со Сделкой, а у меня там адрес но уже с привязкой к гуглу?
Надо как-то привести к общему знаменателю типы данных полей в Универсальных списках и для CRM. Все-таки мы их завязываем между собой и ссылаемся в БП нужно чтобы они совпадали.
ООООчень надо!!!! Срочно!!!
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Такого типа поля в Б24 разве нет? Сам сейчас, увы, глянуть не могу.
Типы данных должны быть системными, а не локальными! И использоваться повсеместно.
Битрикс же изначально предполагал всё строить на инфоблоках, для которых исключительно и была сделана поддержка типов данных в виде пользовательских свойств. Но появлялись новые модули, которым тоже требовались типы данных и они реализовывались для этих модулей "по месту", каждый кто во что горазд, со своим интерфейсом и обработкой, вместо того, чтобы добавить системный тип данных
Появившиеся пользовательские поля использовались вяло, не было глобальной поддержки в объектах, зачастую новые типы данных пользовательских полей реализовывали только ограниченную часть возможностей и функций, типы данных в пользовательских полях до сих пор не синхронизированы с пользовательскими свойствами инфоблоков...
Это не проблема только универсальных списков, это злобная проблема системы в целом. Нет единой, чёткой и повсеместно используемой системы типов данных. Пользовательские поля, которые вроде бы должны были решить проблему, развиваются вяло и не системно, только когда приспичит. Остаются собственные реализации типов данных в модулях, чего стоили хотя бы жёстко зашитые в бизнес-процессы свои реализации типов данных и почти никакая и очень ограниченная поддержка "системных" типов и так далее. Зоопарк, как вы видите, продолжается...
Спрпведливости ради, "radio" это не тип поля, а метод отображения/управления зачением поля с типом "Список немножественный".
Такого типа поля в Б24 разве нет? Сам сейчас, увы, глянуть не могу.
Да, этот тип поля есть в Битрикс24, но не там где его хотели использовать, а именно в Универсальных списках. Поэтому и возник вопрос, как так, система одна, а типы разные......