Сейчас html может накладывать форматирование на поля разных типов (в теге input свойство type), по этому же типу можно формировать шаблоны (например, на поле типа tel накладывать маску телефона)
Но сейчас нет возможности даже определить столь популярный тип как tel (телефонный номер!)

Предлагаю добавить тип поля tel в список настроек полей форм обратной связи и свойств заказов:

пожалуйста оторвите руки тому кто это сделал!!!
https://prnt.sc/nwaqwu

настройка отображения свойств в карточке товара
вызываем параметры компонента, настройки детального просмотра
отмечаем свойства которые нужно отображать
их несколько сотен!!!!
а окошко на три строчки и размер не изменяется

это просто садизм!

У клиента свыше 700 свойств на сайте, при настройке свойств умного фильтра по разделам контент-менеджеры столкнулись с трудностями поиска свойств в обычном <select>.

P.S Как вариант, предлагаю сделать select с поиском, либо реализовать поле выбора (подобно LOCATION) только адаптировать под свойства.

При настройке наборов свойств определённого раздела торгового каталога не хватает поля сортировки свойств для упорядоченного вывода свойств в умном фильтре. Очень хотелось бы увидеть данный функционал.

Уже лет 5 стесняюсь спросить.. А почему у свойства html/тест все смещено вправо?

А давайте как-нибудь придумаем сложную комбинацию, не знаю. Может быть какое-то условие. Хотя не уверен, что можно его придумать, оно же такое сложное.

Но все же, если постараться, сделать такое условие, чтобы заголовок свойства, обозначенного как html/text, располагалось по центру.
А само окошко редактора.. ТОЖЕ располагалось по центру?

Я не слишком много прошу? Раз уж редактор не можете сделать нормальный, то, может быть, хотя бы.. вот это.. немного же прошу. Христа ради. Поможите?

Вы придумали очень удобный инструмент для работы с файлами (и особенно с изображениями). За это вам спасибо.

Правда есть одно "но". Работу по внедрению этого инструмента вы почему-то бросили на половине пути. Я бы мог понять это в начале, когда этот механизм только анонсировался и тестировался, но прошло уже очень значительное время с тех пор.

Сейчас нет возможности создать пользовательское свойство для раздела или HL элемента, который будет работать с drag'n'drop. Нам по прежнему предлагается использовать старые механизмы.

Я уже молчу про то, что файлы по прежнему грузятся по старому во всех других местах, кроме элементов инфоблоков (профиль пользователя, разделы инфоблоков, элементы HL и т.д.).

Собственно идея в том, чтобы довести до ума данный инструмент и внедрить его повсеместно.

Когда товар имеет 2 и более свойств, может меняться ценообразование. (Напримр: Майка - Цвет: Белая/Синяя/Красная - Размер: S/M/X/XL.
Выбор свойств, например, при выставлении счета, позволит уменьшить справочник товаров в 2 и более раз. Не надо создавать множество позиций, но с разными свойствами. Если при этом будет меняться и предустановленная цена - это буде идеально.

Т.е. Мы жмем Добавить товар. В этой сроке сейчас только цена, кол-во и сумма. В эту же строку добавить выбор свойств.

Свойство типа "файл" привели к "нормальному" виду (но всё же идея):


НО как же создать новый файл?
И почему нет превью простых форматов?


Вот как пользоваться CRM если из неё постоянно выходишь в другие программы и сервисы для работы в этой же CRM...(((

Сейчас (sale 17.6.6) из каталожных настроек есть только "по категории товара" (это раздел инфоблока). Не хватает возможности указать свойство и его значение (равно, не равно, отсутствует).

Как пример - не все службы доставки принимают опасные грузы. Это можно было бы оформить в виде удобно настраиваемого ограничения. А сейчас приходится делать свою службу доставки и использовать \Bitrix\Sale\Delivery\Services\Base::isCompatible.

Мы наткнулись на логическое противоречие.
Одинаковые названия свойств товаров и предложений
Например, в одном разделе есть "Товар" (простой товар, без торговых предложений) со свойством "Диаметр резьбы", и в этом же разделе есть "Товар с торговыми предложениями" с точно таким же свойством "Диаметр резьбы", но именно в свойствах инфоблока "Торговые предложения". И нам нужно оба свойства показать в умном фильтре.
Мы это сделали, и у нас отображаются как дубли  http://prntscr.com/htq4wy

Было бы хорошо решить эту проблему, создав в настройках инфоблока функцию "Объединить значения одинаковых свойств в умном фильтре"

Форумчане как Вы считаете, полезны ли иерархические списки с группировкой по какому-либо свойству. К примеру у сущности создал поле которое является списком и хочется как то сгруппировать их, чтобы они не появлялись все когда используешь отображение через флажки (отображение списком по мне ужасная вещь, которая реализована на данный момент в плане множественного выбора).

Есть каталог товаров, 20 разделов. В каждом разделе - у товара 10-15 свойств. Итого, при редактировании товара выводятся все 300 свойств и работать с этим в админке становится нереально.

Идея: дать возможность в инфоблоке указывать для каждого раздела какие свойства отображать при редактировании (возможно - и при отображении в публичной части)

как правило одного поля SORT в b_iblock_element недостаточно для сортировки товаров в ИМ, предлагаю добавить дополнительные поля SORT_1, SORT_N, которые будут заполняется по усмотрению разработчика,
практически везде ведётся предварительный расчёт цен для корректной по цене с учётом скидок.  
цель: не обращаться к таблицам свойств и цен, которые могут быть очень большими

Предлагаю внести вполне очевидную вещь, которой почему то досихпор не реализовано. В 1с есть дополнительные реквизиты, они же свойства в БУС. В 1с они все упорядочены, однако при выгрузке он не учитывает индекс сортировки и выгружает свойства в хаотичном порядке. Соответственно когда в каталоге более тысячи свойств, вручную их сортировать становится непосильной задачей.

Доброго времени суток, уважаемые.
Идея тут появилась, а почему нет у инфоблоков свойства с привязкой к местоположению модуля sale ? В случае такой необходимости, приходится создавать дополнительный справочник и руками его наполнять, так почему бы не реализовать такой свойство?

При использовании свойства типа 'Дата/время' оно храниться как текст в БД, что не правильно абсолютно ни с какой точки зрения.

Админка:



В БД: