Добавьте, пожалуйста, в тип данных пользовательского поля в задачах - список.

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

В модуле "Библиотека документов" была попытка реализовать пользовательские поля. Это даже частично работало, поля добавлялись в библиотеку и даже выводились в шаблон списка документов, но поиск по ним так и не был реализован.

Почему бы это не реализовать в модуле "Диск"? К тому же предпосылки были http://dev.1c-bitrix.ru/community/forums/messages/forum23/topic70895/message371785/#message371785

1. В пользовательских полях, добавляемых к задачам, в числовом поле сделать поддержку знаков после запятой, с возможностью настроить значение поля по умолчанию, количество разрядов и количество знаков.
2. Возможность для пользовательских полей не распространять их на все задачи, а только для тех в которые они устанавливаются пользователем при создании (чтобы другие пользователи их видели только если хотят их добавить в свои задачи, но по умолчанию чтобы их видно небыло).
3. Добавить возможность создавать в качестве пользовательского поля, поле с типом список (маркированный (с множественным выбором или только с одним вариантмо для выбора)/выпадающий).

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

1. пользователям трудно найти их найти
2. пользователе видят все что есть в разделе дополнительно
   

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

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

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

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

Добрый день.

Ситуация: есть тестовый портал на котором тестируется новый функционал, разрабатываются новые бизнес-процессы и так далее. Говоря простым языком - свалка.

Но именно на ней обкатываются и разрабатываются бизнес-процессы для наших клиентов.
Далее БП экспортируется из нашего тестового портала и импортируется в портал клиента.

Вроде всё хорошо, но потом случайным образом, что ВСЕ пользовательские поля для всех сущностей с тестового портала созданы на портале клиента, хотя они вообще НЕ УЧАСТВУЮТ в бизнес-процессе.

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

Спасибо.

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

Поясню: при разработке своего типа полей (наследуемого от другого простого типа) конвертация работает, но для всех полей НЕ относящихся к типам файл. Если отнаследоваться от поля типа файл, то результат не будет конвертирован (т.е. поле будет пустое).

Если копнуть проблему глубже (например с лидами), то "бага" кроется в классе \Bitrix\Crm\Conversion\LeadConversionWizard в методе prepareDataForEdit.
Примерно на 150 строчке есть следующей фрагмент:


Если отнаследоваться от типа файл, создать кастомный обработчик и назвать тип file_extended, то для работы конвертации необходимо заменить следующим фрагментом (например):
Предлагаю сделать либо костыль в виде функции обработчика для возможного расширения данного поля, либо (как правильнее) применить принципы ооп и проверить на абстрактный класс/интерфейс пользовательского поля-родителя.

P.S. Этот "хак" в ядре сотрудники ТП битрикса проигнорировали, сославшись на то, что конвертация "своих типов пользовательских полей не рассматривается в рамках техподдержки"

20 символов, для имени сущности очень мало.

Туда даже не поместится название модуля.

Сделайте хотя бы 30, а лучше 50, чтобы я мог придумывать уникальные имена объектам и не нарушать правила маркетплейса.