CUser::Add создаёт пользователя из кода — в обход штатной
формы регистрации на сайте. Метод нужен при импорте базы клиентов,
при создании учётной записи после оформления гостевого заказа
или при синхронизации с внешней системой.
Базовый вызов
<?php
$user = new CUser;
$fields = [
'LOGIN' => 'ivan_petrov',
'EMAIL' => 'ivan@example.com',
'PASSWORD' => 'x7K9mPq2',
'CONFIRM_PASSWORD' => 'x7K9mPq2',
'NAME' => 'Иван',
'LAST_NAME' => 'Петров',
'ACTIVE' => 'Y',
'GROUP_ID' => [5], // группы, в которые добавить пользователя
];
$id = $user->Add($fields);
if ($id) {
echo 'Создан пользователь с ID ' . $id;
} else {
echo 'Ошибка: ' . $user->LAST_ERROR;
}
Обязательные поля — EMAIL, PASSWORD
и CONFIRM_PASSWORD, которые должны совпадать. LOGIN
не обязателен: если его не указать, а в настройках модуля включена
авторизация по email, логином станет сам адрес почты.
Проверка результата
Метод возвращает идентификатор нового пользователя при успехе
или false при ошибке — например, если email уже занят
или пароль не прошёл проверку сложности. Текст ошибки доступен
в свойстве LAST_ERROR объекта.
<?php
$user = new CUser;
$id = $user->Add($fields);
if (!$id) {
\Bitrix\Main\Diag\Debug::writeToFile(
$user->LAST_ERROR,
'CUser::Add',
'/local/logs/users.log'
);
}
Нужна помощь с Битрикс?
Автоматическая генерация пароля
Если пароль не задан явно, система сгенерирует его сама и, при включённых почтовых уведомлениях, отправит новому пользователю письмо с данными для входа. Такой сценарий типичен для создания учётной записи после оформления гостевого заказа: покупатель ещё не думал о пароле, а сайт заводит ему аккаунт и присылает доступ отдельным письмом.
Добавление в группы
Параметр GROUP_ID принимает массив идентификаторов групп —
пользователь сразу оказывается во всех перечисленных. Если параметр
не передан, пользователь попадает в группу по умолчанию, заданную
в настройках регистрации главного модуля.
Практический сценарий импорта: клиенты, загружаемые из внешней CRM как оптовые, сразу добавляются в группу «Оптовики», которая связана с отдельным типом цены каталога.
Заполнение своих полей при создании
<?php
$fields = [
'EMAIL' => 'ivan@example.com',
'PASSWORD' => $generatedPassword,
'CONFIRM_PASSWORD' => $generatedPassword,
'UF_PHONE' => '+79001234567',
'UF_SOURCE' => 'import_1c',
];
$id = (new CUser)->Add($fields);
UF-поля заполняются в том же массиве, что и стандартные — отдельного вызова не требуется, если поле уже создано в административной части.
Массовый импорт
При импорте сотен и тысяч записей стоит помнить про два практических
момента: проверку уникальности email до вызова Add,
чтобы не тратить время на заведомо неудачные попытки, и разбиение
импорта на порции с сохранением позиции — та же логика, что и при
других длительных операциях, разобранная в контексте ограничения
времени выполнения скрипта.
<?php
foreach ($importBatch as $row) {
$existing = CUser::GetList('ID', 'ASC', ['EMAIL' => $row['email']])->Fetch();
if ($existing) {
continue; // пользователь уже есть, пропускаем
}
$user = new CUser;
$id = $user->Add([
'EMAIL' => $row['email'],
'NAME' => $row['name'],
'PASSWORD' => bin2hex(random_bytes(6)),
'CONFIRM_PASSWORD' => null, // заполняется тем же значением ниже
]);
}
Частые ошибки
-
Не совпадают
PASSWORDиCONFIRM_PASSWORD. Метод вернёт ошибку, а не создаст пользователя с одним из значений. - Не проверяется уникальность email перед импортом. Массовая загрузка тратит время на попытки, заведомо обречённые на ошибку дубля.
- Результат не проверяется. Скрипт продолжает работу, считая, что пользователь создан.
- Группа по умолчанию даёт лишние права. Импортированные пользователи неожиданно получают доступ, не предназначенный для них.
Итог
CUser::Add создаёт пользователя из кода с теми же полями,
что доступны в форме регистрации, плюс возможность сразу назначить группы
и заполнить UF-поля. Для массового импорта стоит заранее проверять
уникальность email и всегда контролировать результат вызова —
сообщение об ошибке лежит в LAST_ERROR и объясняет,
что именно не позволило создать запись.
