При оформлении заказа присваивается 100% скидка на заказ.
в истории имеем: "Discount specified manually during order creation: -2,587" (это 100% суммы заказа)
При чем эта запись появляется раньше, чем "Имя пользователя Order was placed"
Условия появления бага:
Заказ оформляет пользователь из фронтэнда, пользователь создается при оформлении заказа, это первый заказ пользователя, скидки в магазине отключены, плагинов для скидок не установлено.
Думал, что я сам что-то поломал в магазине, но наблюдаю такую радость уже на двух магазинах. Повторить баг не удается, баг не имеет каких-то видимых алгоритмов появления или периодичности...
Вот кусок истории заказа

Может дырку наши? (ну или дырочку....)
В логах следов не нашел....
23 комментария
А посмотреть действия пользователя через метрику не пробовали?
метрика не подключена.
Подключена гугл аналитика подключена.
В ней вроде нет видео просмотра действий, подключить хотя-бы временно метрику этим клиентам, чтобы выяснить, какие действия производит пользователь, которые приводят к данным последствиям (если конечно он не блокирует скрипты метрики).
Глянул на втором сайте - там подключена. Ни чего сверхестественного не делает. все как всегда....
похоже на дырочку. Вручную только пользователь бэка может
Была б дырка - тут бы уж шум стоял. А так только у Павла... И на 2 сайтах... Значит есть какая-то особенность, ну или звезды сойтись должны... Имхо, ессно.
Никаких скидочных плагинов дополнительных не подключено? Не удается воспроизвести пока.
Либо кто-то как-то куку админскую угнал :-/
Если ставится вручную, то это происходит после оформления заказа, а здесь запись ДО. Так же есть инфа - кто именно из юзеров установил скидку. Доступ извне к админке маловероятен. Разве что - API или дырка
Так же доступ в админку только двум IP открыт.
если в бэке делаешь заказ, можно сразу вручную скидку указать. кажется, это оно.
А у того, от чьего имени скидка дана имя не поменялось? Лишнего адреса в профиле не добавилось?
Нужно значит подключать Вебасистовцев, они должны быть в этом заинтересованы больше всех. Хотя с их отношением к исправлениям не знаю как быстро они что то сделают.
А я бы на вашем месте включил все логи php и MySQL (лог SQL запросов) так же логи запросов в веб серверу, с ежедневной ротацией. Временно до обнаружения проблемы. Ну и IDS не помешает, "а чо? а вдруг?" )))
да... займусь этим...
Так а что со скидочными плагинами?
Я ж писал в первом посте - отключены
точнее - на одном сайте вообще нет скидочных плагинов и скидки отключены, а во втором используются гибкие скидки
проверил все записи в таблицах по этому заказу - все как всегда.
Реферы, страницы и т.д. - ни чем не отличается от остальных
Я бы еще прицепился к order_action.create и посмотрел, что там.
Насколько я помню (когда-то экспериментировал) скидка по заказу пишется одной из первых строк, если при записи заказа указать в массиве заказа discount
Паш, начни с простого: проверь .htaccess в нужных местах. Ну так, на всякий случай...
Та уже перекопал его. Админка закрыта даже по IP. Тудой не пролезут. Это или глюк или кто-то дырку наковырял
Такое возможно получить, например, если в обработчике хука order_calculate_discount написать $params['order']['discount'] = $params['order']['total'];
Поскольку передаётся по ссылке, то это меняет основную переменную заказа.
А дальше уже отрабатывает код в классе shopWorkflowCreateAction.class.php :
И как раз получается такая картина.
Но повторюсь, это возможно, если стоит кривой плагин, который вместо того, чтобы вернуть скидку просто меняет discount у заказа.
Так что внимательно посмотрите на установленные плагины (возможно вы сами в каком-то плагине что-то тестили и забыли).
Других причин судя по коду нет и быть не может.
Я понял как они это делали!!!!
Знач эти хитро-жо... товарищи добавляли в корзину отрицательное кол-во товара. (на странице товара у меня выведено поле для ввода кол-ва)
В корзине мы получаем нуллевую итоговую сумму и скидку = сумме товара.
Заметить в админке минус рядом с кол-вом товара - не так просто. На цифру смотришь, а минус как-то и не видишь.
сделал проверку при изменении поля кол-ва.
ИМХО: Это баг движка. проверка таких вещей должна быть на уровне исходного кода
Великолепно! :)
и действительно
Но вот толку с таких заказов? :)
Спокойно можно прямо в коде поменять.
Представьте, что у Вас в день по 500-1000 заказов, персонала больше 100 чел.
Какова вероятность, что такой заказ проскочит и будет доставлен?
Ушёл писать бота.
Жесть, почему это до сих пор работает?!