| Цитата |
|---|
| 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 (потому что сайт просит)? Бабушка получит и оплатит, это она клиент.
Поддержите идею (выбор имени файла для robots.txt в многосайтовой конфигурации на общей папке)! А убит сайт идей. Фсё!
