waResearchLab

Это не ошибка, это штатная ситуация для метаобновлений.

Из практических навскидку могу назвать 2 задачи, которые по моему мнению достаточно критичны:

1. Актуализация остатков в маркетплейсах. Если магазин работает достаточно активно (а если магазин размещен на нескольких маркетплейсах, то заказы приходят достаточно часто, до 300 в сутки), то чтобы не актуализировать остатки по всему ассортименту магазина на маркетплейсе хотелось бы делать это с некоторой периодичностью (например раз в час по всему ассортименту) + точечно по тем товарам, у которых изменились остатки. А для этого нужен хук, потому как без него - это гопак на костыле с выподвывертами, не дающий гарантированного результата. Это важно потому, что если на каком-либо маркетплейсе закажут товар по которому с момента последней полной актуализации остатков были изменения (например купили 5 штук на другом маркетплейсе и на складе товар закончился)  и продавец не сможет выполнить свои обязательства, то это приведет к понижению его рейтинга с соответствующими финансовыми потерями.
2. "Лучше горькая но правда, чем приятная, но лесть" (с)  =)   В SS система списания ооочень дубовая. Зачастую пользователю необходимы разные условия для списания товаров с того или иного склада. Да хотя бы обеспечить чтобы склад не уходил в минус. На эту тему есть пара плагинов, один из которых снят с продажи именно по тойцпричине, что исполнение гопака на костыле с выподвывертами не дает гарантированного результата, и всех вариаций учесть никак не получается, т.к. не удается гарантированно понять - списание произошло/изменилось или нет, и до складов процесс не доходил. В общем там много всего, и такой хук позволил бы очень упростить работу и дать пользователям дополнительный инструмент по списаниям с конкретных складов по разным условиям.

1. В моем конкретном случае важен лишь факт списания. ID артикула и товара, подлежащее списанию количество с каждого склада.
2. Не претендую на полный ответ, но знаю точно что возможность изменять склад списания и количество будут очень очень полезны
3. Да, лучше оба варианта.

Создает. По крайней мере в части интеграции с маркетплейсами. Думаю, коллеги имеющие в своем арсенале инструменты интеграции меня поддержат. Для маркетплейсов надо обязательно передавать габариты товара. И если в настройках Shop-Script для габаритов выбрана характеристика с таким типом, а у товара габариты проставлены для каждого артикула - то тут начинается знатная пляска. В рамках своего инструмента "плясать" не начинал, т.к. считаю это ошибкой Shop-Script и крайне не хочется городить огород из-за нее.

Вариант хранить информацию о габаритах для маркетплейсов дополнительно в других характеристиках (при условии что в настройках магазина указана число*число*число) априори считаю унылым.

На всякий случай уточню: вижу тут проблему в формате получаемых от Shop-Script данных. Ожидался единый формат в обоих случаях.

Посмотрите эти статьи:

https://support.webasyst.ru/sh...

https://support.webasyst.ru/sh...

Думаю, что правильным решением было бы не добавление нового хука, а интеграция коллекций в автокомплит.

Да, согласен.

для выполнения массовых действий со стандартными и собственными коллекциями

Массовое исключение товаров из списков, Массовое исключение товаров из категорий (ссылки в правом сайдбаре)

добавляете ссылку в боковое меню или в какое-то другое место в панели управления, чтобы пользователь мог открыть некий нестандартный список товаров

Фильтр и поиск товаров в бекенде, ВКонтакте: Интеграция, ВКонтакте: Товары, Озон: Интеграция. 
В этих плагинах элементы управления расположены в верхнем тулбаре и левом сайдбаре.

Если абстрагироваться от панели управления товарами, то коллекции активно используются в Автоматическое управление товарами

Напомним, что максимальный срок проведения промоакции остался прежним — 10 дней.

=)

Да. Используйте штатные классы, методы и модели:

https://developers.webasyst.ru...

https://developers.webasyst.ru...

и пр.

В CRM и Поддержке вообще есть мегахуки

А теперь и в Shop-Script

не столь популярны

На удивление, наблюдаю что CRM относительно активно пользуются.

Остальные приложения идут довеском к Shop-Script

Такие приложения вообще надо выжигать напалмом из маркета Webasyst. Хочешь сделать что-то прикладное - плагин для SS или для Сайта

никто не создает блоги или форумы на Webasyst...

Создают. Может не так много, но примеров достаточно.

Для приложений которые не являются по сути приложениями я б вообще процент поднял.

А вот сама идея здравая, не могу не поддержать.

Ну ок, пусть так. Спасибо.

Но интерфейс приложения становится недоступным — блокируется на системном уровне большой растяжкой с предложением купить продление

Получается, аналогичная картина будет и для приложений на которые вообще нет лицензии?

А с другими типами продуктов аналогично, или это касается только приложений?

Ключевое: мотивация разработчиков плагинов.

Я, как мне кажется, понимаю причины и принимаю озвученный подход. Но мне категорически не нравится то, что эта возможность предусмотрена для любых приложений, вне зависимости от их функционала. Есть опасения, что часть плагинов могут начать переходить в приложения. То что наплагины подобная система не будет распространяться - ну что поделать. Но нужны какие-то стимулы и мотивация и для "плагинописателей".

Выборка, конечно, крайне маленькая, но весьма показательно, что ни один из опрошенных не планирует арендовывать приложения на длительный срок, предпочитая старую-добрую "покупку навсегда":

Из своей небольшой выборки могу сказать что порядка 30-40% предпочли (именно предпочли, а не предпочли бы) ежемесячную аренду покупке. Да и про пример облака WA забывать не стоит.

Все аргументы сводятся к тому, что...

Наш бессмысленный диалог идет на разных языках и о разных вещах. Вы мне про тыщи, я вам про систему =)

Что-то, коллеги, вы ночью решили поспорить о шкуре неубитого медведя.

Ну я говорил исключительно о концепции, не более того. Согласен, рассуждать о конкретике смысла нет.

Уже называл на других площадках, но повторюсь, хотя может и другими словами.

- Кому апельсины, кому витамины.
- По чём?
- Рубль штучка, три рубля кучка, а в кучке три штучки.

Эта цитата из известного к/ф - прямое отражение оплаты за конкретное обновление. Концептуально - это базарный подход. "Я пыхтел, что-то делал, продаю за столько-то". Но интернет-магазин - это все же бизнес. Говорю именно про ИМ т.к. основное содержание маркета WA крутится вокруг SS и без него практической ценности не имеет. Так вот эти ИМ могут быть крупными, средними, мелкими, с настроенными бизнес-процессами и без таковых, с какой-то стратегией развития и развивающиеся на авось, процветающие и затухающие как болото. Но в любом случае это какой-никакой, но бизнес. А для бизнеса важно планирование и понимание куда идём, зачем идём и, в том числе, сколько это будет стоить. Это называется планирование. Так вот предлагаемый подход ставит крест на планировании для микро, мини, и средних магазинов. И если для средних магазинов и части мелких сумма в пускай 50-70к рублей в год это не столь критично, то для микро магазинов, коих в среде WA на мой взгляд подавляющее большинство, это будет критично. Откуда цифра в 50-70к? Взял среднее количество установленных плагинов в 40 штук, умножил на 300р и на 4 обновления в год. Но только какие-то обновления будут и не по 300р... Вот и получится такая сумма. А если дать возможность всем использовать такую лицензионную политику - редкая "птица" по доброй волей ею не воспользуется. И тут я WA полностью понимаю. Если огульно внедрить вот так на все продукты - начнется бардак в результате которого резко повысятся затраты на содержание магазина с сомнительным выхлопом в части качества обновлений. Как следствие - лояльность пользователей поползет вниз. Вот и весь итог этого псевдорешения. Разговоры о том что со временем все само утрясётся - разговоры в пользу бедных. Лояльность повысить будет намного сложнее и дольше. Лицензионная политика - это система стремящаяся к универсальности. Плата за каждое обновление по желанию разработчика - это дубовый подход, не учитывающий ни чьих интересов, кроме сомнительных интересов разработчика, который, кроме всего прочего, нарушает базовый принцип всего и вся - не навреди.

Подписка на обновление в этом плане намного более гибкий инструмент. И главное его преимущество - он дает возможность планирования затрат, что для микромагазинов является если не определяющим, то достаточно критичным фактором. Не нравится формулировка - назовите как угодно: "Абонемент на обновление", "Взнос на развитие", "Поддержка проекта". Абсолютно не важно (для адекватных людей). Но и с подпиской надо знать меру. Если проецировать схему используемую в SS, то льготное продление не должно превышать 10-15% от стоимости продукта. Полная же сумма - не более 25%. Ну это навскидку. Почему? Тоже все просто. Надо помнить, что у конечного пользователя таких продуктов десятки. И суммарно набегает вполне прилично с т.з. основной массы микромагазинов. 

Ну и чтоб два раза не вставать. Я, честно говоря, не вижу толкового решения без того, чтоб WA взял на себя дополнительную нагрузку в части "сортировки" продуктов и разработчиков. Да, будут недовольные, да, будут возникать вопросы. Но от этого никуда не деться. Разве их не будет со стороны пользователей если будет внедрена озвученная схема? Будут. Со стороны разработчиков их уже прилично. Когда речь идет о какой-то системе затрагивающей более или менее широкую  аудиторию - всегда будут недовольные. На любое предложение всегда можно найти контраргумент начинающийся со слов "А если я захочу...". Но лицензионная политика - это не червонец, всем нравиться не будет. Но она должна преследуя поставленные цели учитывать интересы всех сторон. Поэтому  это очень важный вопрос, к которому надо отнестись с максимальным вниманием. А базарный подход тут не пройдет.

Плата за конкретное обновление - решение

Нет, это крайне неудачный костыль, при попытке опереться на который он сломается и обломком проткнет грудную клетку со всем отсюда вытекающим =)

Концептуальный затык ситуации в том, что априори не все разработчики будут добросовестными вкупе с тем, что WA категорически не хочет брать на себя роль третейского судьи (другими словами - не имеет никакой внятной политики работы с партнерами). Если убрать хоть одну из перечисленных выше составляющих - все сразу встанет на свои места.

Плата за конкретное/каждое обновление - абсурд.

Логика сомнительная

Логика нормальная. На сознательность разработчиков рассчитывать не приходится. Как следствие, любой пшик будет мнить себя центром вселенной и требовать платы за обновки, что отрицательно скажется на общей лояльности к фреймворку. Тут я с Webasyst согласен.

Да и много ли приложений действительно можно назвать "сложным решением", которое достойно быть приложением?

Мало =) И чем дальше - тем меньше (в процентном соотношении). Этот вопрос , хоть и немного в другом разрезе, поднимался мной еще ооочень давно. 

И вот что действительно логично: зачем что-то менять тогда в плагине, если всё работает?

Согласен с коллегой. У разработчика нет никакого стимула делать качественные и функциональные продукты (плагины). А плагины - это более 80% от всего маркета. Новые продажи это конечно хорошо. Но если продукт себя уже зарекомендовал, то я не вижу глубинного смысла с т.з. разработчика продолжать его активно развивать. Отсутствие подписки на плагины, на мой взгляд, приведет к постепенной деградации этого сегмента. Разработчики начнут "уходить" в псевдоприложения, и начнется бардак. И их можно понять. Выбранный Webasyst подход - щелчок по носу таким разработчикам как например Syrnik или Igor Gaponov, продукты которых, смею предположить, установлены на 90% всех установок фреймворка. А возьмите к примеру первую десятку из рейтинга разработчиков, уберите на месяц-два их продукты из маркета и попробуйте для себя ответить на вопрос: а как и насколько изменится коэффициент лояльности (или назовите как хотите, суть надеюсь понятна) конечных потребителей к Shop-Script? Что-то мне подсказывает, что ответ будет не самым обнадеживающим. Но сейчас вы этим самым разработчикам говорите: "Плагины конечно хорошо, но если хотите вы хотите развивать то направление вашего бизнеса, которое связано с разработкой под  WA - делайте другие продукты. Суть не важна, главное оформляйте в виде приложений" . Да, у  Webasyst могут быть другие слова, своя аргументация, но это не меняет сути вопроса. Озвученная Webasyst аргументация "против" мне понятна и я с ней согласен. Но я категорически не согласен с озвученным решением. Это первый шаг к хаосу. 

Краткий итог всему написанному с элементами моих прогнозов развития ситуации.

Webasyst не хочет снижения лояльности конечного пользователя к SS и фреймворку. Так же Webasyst не хочет увеличения (в финансовом смысле) входного порога в мир Webasyst.

Что будет: с введением такой однобокой политики лицензирования качественного скачка в приложениях не произойдет. Увеличится количество псевдоприложений, которые будут являться прикладным продуктом к другому основному. Количество качественных приложений в истинном понимании этого термина никак не изменится. Они периодически будут появляться. Но они бы появлялись и без этого нововведения.

Что будет с плагинами: допускаю, начнут появляться вtрсии PRO, Extra, SuperMegaExtra и пр. вариации уже существующих и зарекомендовавших себя продуктов. Параллельно с этим постепенно будет увеличиваться их стоимость. Т.о. цель априори не будет достигнута: входной порог будет расти, маркет будет пухнуть от раздвоения и разтроения плагинов, лояльность потребителя тоже не вырастет.

Что делать? Предложенная политика лицензирования должна распространяться на все продукты. Но т.к. опасения вполне логичны  и ожидаемы, тут не обойтись без введения экспертной оценки WA, с выдачей добра таможней WA применения такой политики к конкретным продуктам, вне зависимости от их типа. Именно такой подход позволит качественно развивать уже существующие продукты и послужит стимулом для создания новых качественных инструментов. Ну а достижение высот "Webasyst - не только Shop-Script" никак не зависит от того есть ли плата за обновления или нет. Хорошие продукты появятся при любом раскладе. Но да, плата за обновление будет неплохим бонусом.

Такие плагины буквально можно пересчитать по пальцам. И хотя нам действительно очень хотелось бы дать всем разработчикам плагинов возможность самим решить, какая модель им подходит, есть опасение, что сейчас это будет иметь обратный эффект

Как ни печально, но полностью согласен, все так и будет.

В свете решения по приложениям: будет ли Webasyst накладывать организационные ограничения на создание приложений? Имеется в виду, не ожидает ли WA что теперь вместо, например плагина для приложения Сайт с подпиской на хуки других приложений, будут создаваться псевдоприложения, не имеющие самостоятельного функционала, которые будут носит прикладной характер относительно других приложений (SS, CRM etc)?

80% приложений вовсе не являются приложениями. Это псевдоприложения, которые по сути должны быть плагинами. Очень печально что Webasyst не следит за качеством публикуемых в маркете продуктов, и что приложением там называется любой пшик без какого-либо функционала, и, как следствие, лезет на тулбар.

Отставить "ура". Теперь это сообщение даже после отправленного и опубликованного комментария )))

Какая разница? =)  В поле настроек приводится пример как это будет выглядеть. По факту выглядит иначе. Понятное дело что дело в размере шрифта, но хоть и интерфейсный, но какой никакой, а косячок.

Но проблема в этих строках:

Как видите, ситуация когда фреймворк установлен в подкаталоге просто не учитывается. Приходится второй месяц править руками.

Там же есть

onBgClick (function) — событие при клике по фону диалога.

function(event, $dialog, dialog_instance) { ... }

Не надо оставлять возможность хорошей оценки без комментариев.  Могу набрать с пяток отзывов с оценкой 5 которых бы лучше и не было. И если оспорить отзыв с плохой оценкой еще есть теоретическая возможность, то у меня ни разу не получалось оспорить отзыв с хорошей оценкой. А уж от оценки без комментария и вовсе проку никакого.

Решено добавлением

<script type="text/javascript" src="{$wa_url}wa-content/js/jquery-wa/wa.js"></script>

И как именно не работает — какой ответ присылает сервер?

При использовании 

profile+license:read

при первичной регистрации/авторизации во всплывающем окне пользователю сообщается что будут доступны только его данные (ФИО,  EMail и т.п.). Соответственно, только эти данные от WA и прилетают. При использовании же

license:read

при той же первичной регистрации/авторизации сообщается что будут доступны как  ФИО и пр, так и собственные лицензии.  Соответственно, от WA прилетает и то и другое.

с каким контактом (contact_id) на каком сайте (client_id) это не работает

Зависимости от clien_id и contact_id не выявлено. Проверялось с несколькими комбинациями обоих параметров.