Добрый день!
Думаю, что будет полезно и удобно, если системные плагины тоже смогут назначать свои обработчики для событий и добавлять записи в роутинг.
Например, для расчета доставки в бэкенде при формировании заказа менеджером.
Разрабатывать второй прокси-плагин, как-то не очень правильно.
Что скажете?
10 комментариев
+
Для платежных плагинов точка входа есть. Так же как и методы взаимодействия (refund и т.п. пока еще в разработке, но уже есть список плагинов, в которых это востребовано).
Для плагинов доставки есть методы взаимодействия. Если их недостаточно, то называйте виды взаимодействия, которых не хватает с оглядкой на остальные плагины.
Сейчас, при редактировании заказа стоимость доставки пересчитывается автоматически.
В бэкенде это сделано немного криво. :) Чтобы плагин считающий доставку по внешнему API сработал, надо указать адрес, сохранить заказ и открыть заказ на редактирование. Иначе оно адрес доставки не видит. Та же фигня с плагинами, которые не на все регионы работают — чтобы увидеть вариант доставки, надо его изменить, сохранить заказ, открыть на редактирвоание снова.
И если в контактах у клиента указана страна, скажем, Беларусь, то заказ с адресом доставки в РФ не посчитается, будут варианты доставки для Беларуси. Пока в контактах страну не сменишь у клиента. (вот не знаю, это может уже и порпавили)
Не хватает по меньшей мере унификации функционала фронтенда и бэкенда.
Почему в карточку заказа, с которой работает менеджер из бэкенда, невозможно вставить кастомную логику — поля (метод customFields), хуки для изменения/дополнения стандартной логики расчета доставки в бэкенде?
см. мой комментарий с usecase'ом ниже.
Владислав, две недели прошло. В техподдержке отправляют обратно в форум. Давайте вернемся к обсуждению вопроса.
Плагин доставки (и остальные), теоретически, могут использоваться всеми приложениями. И однозначного роутинга к ним при таком подходе не получится.
Не мое дело, конечно, но ручной расчет менеджером в бэке какбэ намекает на недостаточно хорошую организацию фронтэнда и работы магазна вообще. Когда начинают звонить клиенты с вопросом "сколько будет стоить доставка?", наверное, стоит подумать о доработке сайта снаружи, чем о создании инструмента для расчета доствки менеджером.
Впрочем, сделать плагин для расчета менеджером нетрудно, непонятно зачем это встраивать в конкретную доставку. Тогда уж логичнее чтобы показывались сразу все возможные методы и их стоимость.
Здесь даже речь не идет о том, сколько эта доставка стоит в отдельности от заказа, а о ручном оформлении заказа менеджером.
Ручное создание заказа менеджером через админку более чем актуально: сложно поверить, но существуют покупатели, для которых положить товар в корзину и оформить заказ — задача нетривиальная, либо им просто лень это делать и они звонят по телефону.
И вот как раз в этом сценарии и требуются срабатывание обработчиков событий — кривой (вы сами об этом пишете выше) способ расчета доставки в бекенде при создании заказа может захотеться переопределить /дополнить.
Сейчас же приходится (имея плагины расчета стоимости доставки, требующие специальной логики расчета стоимости) делать это за пользователя во фронтенде, предварительно разлогинившись из своей админской учетки, что, согласитесь, не так удобно, чем делать все в едином интерфейсе.
Тогда надо в саппорт писать и требовать, чтоб исправили баги в оформлении заказа в бэке. А раз уж вы решили свой собственный интерфейс оформления заказа сделать, то опять неясно зачем отдельный роутинг. Логика вызовов и опроса служб доставок будет та же, что и в стандартном, только без багов :)
Решил, что правильнее будет сначала обсудить это на форуме с коллегами, среди которых есть и сотрудники Webasyst.
Баг известный, но вы первый, кого он сильно напряг.
Вот возможность для плагина доставки пользоваться БД — нужная идея. Уж год собираюсь это сделать, но все как-то руки не доходят. :)