Цитата |
---|
wainer написал: как запретить пользователю менять email при оформления покупки |
Программирование + настройки. Есть пользователь сайта, есть профиль покупателя. Вот с этим и нужно разбираться. И решение будет зависеть от версии компоненты оформления заказа и факта конвертации магазина. Сходу не скажешь, нужно просто сесть и сделать.
Цитата |
---|
wainer написал: Вся проблема в том что на синхронизации с 1с я поставил определения физ лиц по emailу) |
Наверняка Вы не одиноки во вселенной. Правда, вот что интересно - генерация ИД покупателя не зависит от того, что оный вколотил в профиле покупателя (в форме заказа):
Код |
---|
if (IntVal($arOrder["USER_ID"]) > 0)
{
$dbUser = CUser::GetByID($arOrder["USER_ID"]);
if ($arUser = $dbUser->Fetch())
$arProp["USER"] = $arUser;
}
|
Код |
---|
<<?=GetMessage("SALE_EXPORT_ID")?>><?=htmlspecialcharsbx(substr($arOrder["USER_ID"]."#".$arProp["USER"]["LOGIN"]."#".$arProp["USER"]["LAST_NAME"]." ".$arProp["USER"]["NAME"]." ".$arProp["USER"]["SECOND_NAME"], 0, 80))?></<?=GetMessage("SALE_EXPORT_ID")?>> |
Вот и пример со "служебным пользователем" (используется на сильно кастомизированном сайте для заказов неавторизованных пользователей):
Цитата |
---|
<Ид>100#serviceuser#Пользователь Служебный</Ид> |
Вот такой ИД контрагента используется ...
Вы сначала по email сопоставляете, а потом по ИД? Ну так и пусть. Есть примеры, когда сопоставляют по номеру телефона (надежнее, говорят).
В Битрикс на каждого пользователя сайта может приходиться с десяток профилей покупателя (это штатный функционал). Более того, он может делать заказы от имени физлица и юрлица. И даже больше - разных физлиц и юрлиц. Стоит ли с этим бороться? Почему внуку Васе нельзя сделать заказ от имени бабушки Марьи Петровны с ее домашним адресом, ее телефоном и липовым email (потому что сайт просит)? Бабушка получит и оплатит, это она клиент.