заказа пробегаться по всем имеющим профилям пользователя пользоватлей. Если в одном из них найду ИНН, который ранее использовался с определенном профиле, то не запретить пользователю оформить заказ.
Тут наверное правильнее подцепиться к OnSaleOrderEntitySaved ?
нет
OnSaleOrderBeforeSaved не даст сохранить заказ
вообще с точки зрения проектного менеджмента, куда эффективнее на этапе чекаута (того же sale.order.ajax) определять подобное условие и выводить соответствующую информацию, вместо сохранения заказа и перехода к оплате
как будто это единственный способ оформить заказ :)
ну тут зависит от регламента, доступов и архитектуры я имел ввиду клиентскую сторону) а то сидит человек, заполняет, оформляет, а ему тут хлобысь... и облом а так пошел оформлять, и сразу видит, что смысла нету
ну тут уже не эффективнее, а дополнительно юзер френдли интерфейс...
ну да, может и так
У клиента такая логика была: у него оптовые продажи изделей. Доступ к ценам есть только у зарегистрированного пользователя. Далее у этого пользователя могут быть разные огрнизации ли контрагенты. В свою очередь это просто разные профили покупатели. И теперь при каждом добавление нового профиля необходимо делать проверку занят ли текущий инн или нет у другого пользователя. Если занят, то выдать предупреждение и не давать совершить заказ пока он не укажет свободный ИНН
Предлагаешь прямо скопировать шаблон компонента и дописать просто Js?
Обработчик на регистрацию пользователя повесил. По профилям пробежался и в волочильня. Но на оформление заказа отрабатывает другое событие, вот в поиске идеального варианта )
Завтра попробую через него цепонуть информацию. Может удастся заблокировать регистрацию
по мне куда проще в шаблоне отработать, чем событий плодить главное чтоб потом в этом шаблоне не запутаться, особенно в том js c 8000+ строчек кода) у меня все эти задачи решаются быстро благодаря собственному чекауту, в коробке черт ногу сломит, с одной стороны слишком динамично, с друой стороны слишком много кастомизаций и костылей приходится вешать
С другой стороны у меня ведь не супер пупер логика, которая потребовало бы вмешательству и отладку js кода в поиске истинности ))
это сейчас, одно на другое накладывается со временем, проект же развивается, а потом отдача на фронт многомегабайтного массива данных, который браузер еле вытягивает
хочешь быстрее ajax мимо подключения всего и всяк другого варианта и нет :) вся логика шаблона в js
главная проблема этого компонента, что вся логика в js проще иметь логику на бэке, и ajax'ом подгружать изменения и по скорости быстрее получается и расхождений при оформлении не бывает, а то в нескольких проектах сталкивался, когда клиент выбирает доставку, а в сохраненном заказе как будто он ничего не выбирал
не быстрее, т.к. нужно подключается шаблон сайта + вся логика выше компонента оформления + includeComponent скорость кастома быстрее если только
на мелких проектах может и быстрее, когда логика на клиентском железе работает, но на крупных проектах получается быстрее обрабатывать сервером то, что вводит/выбирает клиент, и показывать только то, что он должен видеть даже со всей логикой за пределами компонента на моей практике разница в 100 раз в объеме передачи информации и примерно в 1,5-2,5 раза в скорости плюс на бэке проще логикой оформления заказа оперировать на всех этапах ну естественно роль играет само железо сервера, на крупных проектах оно в любом случае шустренькое будет, а клиентский телефон какой-нибудь этот js может долго отрабатывать
Обсуждают сегодня