На фоне предновогодних глюков БП-ов и зависаний порталов. Меня очень удивило (мягко говоря), что отправить письмо клиенту с БП не получилось, указав в поле получателя {=Document:EMAIL}. (И не говорите мне, что нужно использовать _printable..)

Хотел поздравить всех с НГ.... Знаете куда пришли все письма? Мне на почту! 1200+ писем, мне на почту... На ту с которой я захожу в свою учетную запись. Я понимаю, что множественные поля и всё такое, НО! Зачем они тогда вообще  нужны??? не понимаю...

Надеюсь в Новом Году вы добавите возможность использовать поля Телефон и E-mail в бизнес-процессах..

Предлагаю добавить возможность использовать в аналитических отчетах поля различных типов, не только числовые.
Применение:
1. Для счетов делаем поле "Акт подписан", тип: "да/нет"
2. В аналитическом отчете показываем сумму всех счетов, у которых подписан акт

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

Читать подробнее...

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

Есть комментарий вида:
Источник: Direct Yandex

Дополнительные значения:
HTTP_REFERER: http://yandex.ru/search/?text=канатный парк уфа&clid=2207003&banerid=0201760088&win=171
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 YaBrowser/15.6.2311.5029 Safari/537.36
IP: 31.13.144.41
LANGUAGE: ru
URL_PATH: ?ch=yadirect&utm_source=yadirect&utm_medium=cpc&utm_campaign=vp_ru_search&utm_term=Канатный парк&ad=876032120&type=9&utm_content=k50id|010000003409422630_|cid|12628498|gid|679525374|aid|876032120|adp|no|kw|Канатный парк|pos|other4|main&k50id=010000003409422630_&_openstat=ZGlyZWN0LnlhbmRleC5ydTsxMjYyODQ5ODs4NzYwMzIxMjA7eWFuZGV4LnJ­1Omd1YXJhbnRlZQ&yclid=5887501543135388120
utm_campaign: vp_ru_search
utm_medium: cpc
utm_term: Канатный парк

Хотелось бы иметь отдельные поля utm_campaign, utm_medium, utm_term и т.д. и чтобы они заполнялись при добавлении.

Есть ли какие-то пути реализации этого?

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

Для полноценной работы не хватает возможности добавления пользовательских полей в товары в облачной версии битрикс24.  
Необходимо например для фиксации остатков на складе при интеграции со другими сервисами типа "мой склад"  

Очень странно почему именно в товарах нет возможности добавлять пользовательское поле?

После тестового периода мы наткнулись на несовершенство поиска по системе.
например невозможность найти компанию/контакт по e-mail - который в ряде сервисов является уникальным ключом для поиска

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

Сейчас в задачах есть возможность создавать пользовательские поля - это прекрасно
Зачастую эти поля было бы удобно использовать при построении отчёта.
Например, мы ведём учёт работ для клиентов с помощью задач в кор-портале. Менеджер при постановке задачи указывает номер счёта, по которому клиент оплатил работу. В конце месяца работник может сформировать отчёт из своих закрытых задач, в котором есть номера счетов, и трудозатраты.
Необходим вывод юзерфилда в отчёте
Также есть необходимость отмечать задачи, оплаченные разработчику, чтобы избежать повторных оплат. Необходим фильтр по юзерфилдам при построении отчёта

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

Решения два:
1. Ввести специальный тип поля "Ссылка", который предназначен для Url адресов.
2. Поля типа "Строка" проверять на наличие Url адреса. Если адрес обнаружен, делать его кликабельным.

Во вложении сравнение стандартного поля для ввода адреса сайта и пользовательского поля со своей ссылкой.

С появлением Highload-блоков и вероятности появления десятков миллионов записей в HL-блоке хочется нормального свойства типа "Строка".

Этому (нормальности) мешает:
1. Невозможность указать допустимый размер свойства "Строка"
Когда вы создаете пользовательское свойство типа "Строка" - отрабатывает класс \CUserTypeString который создает колонку в базе данных по принципу:
Т.е. даже если вы захотите хранить строку длиной 20 символов - все равно получите в разы больше.

Кроме того типовое свойство "Строка" как вы сами можете увидеть не позволит хранить более 2000 символов в Oracle и MS SQL. А ведь есть соответствующие типы.


2. Это можно было бы исправить если бы было событие OnAfterUpdate в классе CAllUserTypeEntity - но его нет. Так что даже в собственном типе свойства не получается невозможным сделать alt er   table.


Хочется обратить внимание разработчиков 1С-Битрикс на комментарий в файле /bitrix/modules/main/classes/general/usertype.php на строке 563:
* Надо сказать, что для скорейшего завершения разработки было решено пока не реализовывать такую же гибкость как в инфоблоках (обойдемся пока без alter'ов и прочего).


Может пора вернуться и доделать те самые alter-ы и прочее (события)?