← Назад к заметкам

Заметки

Как подключить кастомное поле userfieldtype.add

Как подключить кастомный тип пользовательского поля через userfieldtype.add: JS, обработчик, сохранение значения и placement.call('setValue').

В заметке разбираем тему: Как подключить кастомное поле userfieldtype.add. Главное — не переносить решение вслепую с другого портала, а проверить контекст коробки, права, версию модулей и фактические данные.

Задача

Как подключить кастомный тип пользовательского поля через userfieldtype.add: JS, обработчик, сохранение значения и placement.call('setValue').

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

Ключевые вещи в этой теме: userfieldtype.add, setValue, placement.call. Именно их стоит проверить первыми, прежде чем менять код.

Как это устроено

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

Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.

Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.

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

Рабочий подход

Сначала зафиксируйте контекст, потом проверяйте API и только после этого меняйте данные.

  • Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
  • Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
  • Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
  • Для боевого портала добавьте логирование результата и ошибок.

Частые ошибки

Большинство проблем появляется из-за неверного контекста или обхода штатной логики.

  • Код проверяют только под администратором, а потом он не работает у сотрудников.
  • Доработку кладут в /bitrix или в перегруженный init.php вместо /local или модуля.
  • Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
  • Данные меняют напрямую, минуя операции, события, права, индексы и кеш.

Минимальный пример

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

BX24.callMethod(
    'userfieldtype.add',
    {
        USER_TYPE_ID: 'custom_text_picker',
        HANDLER: 'https://example.com/field-handler.php',
        TITLE: 'Кастомное поле',
    },
    function (result) {
        console.log(result.data());
    }
);

function setFieldValue(value) {
    BX24.placement.call('setValue', value, function () {});
}