Следует учитывать, что cron.php запускается из командной строки, соответственно во время обработки события нельзя полагаться на автоматическое определение ID текущего сайта. Функция RS::Site::Manager::getSiteId() - будет возвращать id сайта по-умолчанию.
Рассмотрим проблему на примере \Shop\Model\UserStatusApi::getStatusesIdByType().
Метод выбирает данные для текущего сайта ->where(['site_id' => SiteManager::getSiteId()]), возможность задать сайт(ы) не меняя SiteManager::$site отсутствует. Это автоматически делает подобные методы бесполезными при запуске в консольном режиме

Очень и очень необходим новый редактор для работы с текстом, фотогравиями, видео.
Сейчас шататный редактор редискрипта это полный атас. При открытии статьи под адаптивкой на телефоне все "едет и плывет" во все стороны. Как следствие уведомление об ошибках в серч консоле гугла, а также репутация в глазах клиентов как "руко@опого сайта".
Уважаемые разработчики, пожалуйста сделайте нормальный редактор. Или озвучте за сколько вы готовы его запилить.
6 редискрипт с отличной дефолтной темой вы ведь сделали, пришло время и для нормального редактора.

Сокрытие ненужных полей в карточке добавления товара

Есть одно пожелание и его нужно доработать.
При создании пожелания, там где сначала можно поискать похожее пожелание в поиске по пожеланиям.
Пожелание такое: нужно сделать так, что, если похожее пожелание не найдено, то при нажатии на кнопку "Написать пожелание" , из поля поиска, тема запрашиваемого пожелания чтобы переносилась в тему создания нового пожелания )
Каждый раз когда пишу пожелание, эта проблема напрягает.

Здравствуйте!
Встроенная функциональность модуля доставки СДЕК вряд ли востребована большинством магазинов, только по причине обязательного расчёта стоимостью доставки. Цена доставки сугубо индивидуальная вещь, она зависит от множества факторов, где-то порой нужно сделать завышенную доставку в каких-то случаев нужно наоборот занизить стоимость или вообще убрать. Порой разнородность товара не позволяет автоматически рассчитывать доставку по тем или иным причинам. А вот удобство, быстрота и ясность дальнейших действий при оформлении заказа, будет востребована как администратором так и покупателем. По этому прошу вас рассмотреть возможность разработки следующего функционала:
Модуль СДЕК
Задача минимум
Покупатель при оформлении заказа выбирает доставку СДЕК, далее выбирает нужный пункт выдачи на основе геолокации, при этом рассчитывать цену доставки не нужно, вместо цены текст – «будет рассчитана менеджером», можно отобразить сроки доставки. Информация о выбранном пункте выдачи поступает в заказ администратору и покупателю.
Примеры готовых виджетов можно найти на сайте СДЕК https://classic.cdek.ru/website/edostavka/upload/custom/files/pvzwidget(1).zip
Задача максимум
По аналогии на основе уже встроенного модуля доставки СДЕК – нужно оставить выбор пункта выдачи, но убрать расчёт доставки, сумму доставки должен указывать менеджер при обработке поступившего заказа. Далее администратор формирует накладные и трек для СДЕК по API. Только после этого информация о сформированном треке поступает покупателю. Сейчас трек формируется автоматически покупателем – это плохо, хотя в настройках у вас предусмотрена возможность отключать автоматически создавать трек на стороне СДЕКа но тогда почему-то не приходит информация о выбранном покупателем пункте выдачи ни админу ни покупателю.

Надеюсь внятно изъяснился, заранее спасибо!

Здравствуйте! В настройках карточки товара нужна функция истории изменения.
Пример:
1. Информация о том, кто из пользователей создал товар.
2. Информация о том, кто последний раз редактировал товар.
3. Информация о том, какие поля менялись в товаре.

В данный момент через yml файлик нет возможности загрузить многомерные комплектации и вариации товара (цвет,размер).
Обычно в yml все варианты одного товара идут под единым group id.

Текущий механизм импорта комплектаций подразумевает выбор изображения для комплектации из уже загруженных в систему.
Но, иногда бывают ситуации, когда мы формируем csv, не обращаясь к системе ридискрипт. Вернее, так бывает всегда :) Просто далеко не всегда сложные (и нелогичные) прайсы от поставщиков приходят.

В общем, нужен механизм загрузки изображений в момент импорта комплектаций. Пусть это будет дополнительное поле, которое мы будем использовать, когда действительно нужно загрузить в систему новые изображения. Если же мы хотим использовать уже существующие изображения, то используем поле "Фотографии".

***
Поясняю для обывателей, кто редко комплектациями пользуется.
Допустим, есть товар Шапка, у него три комплектации на цвет - синяя, красная и зелёная; и три комплектации на размер - 1, 2, 3. Получается многомерная комплектация.
А теперь представьте, что таких Шапок у нас 2000 штук. И у каждого цвета каждой шапки своя картинка.

Пытаемся это загрузить. Допустим, загрузили всё как товары - проблем не будет, мы можем грузить как с пути к фотке относительно сайта, как с абсолютного url картинки (это медленнее, но Readyscript загрузит), а также просто с zip-архива. Вместо одного товара получилось три товара - Шапка Мономаха синяя, Шапка Мономаха красная и Шапка Мономаха зелёная. Пути к загруженным изображениям выглядят как /storage/photo/original...
При импорте комплектаций поверх товаров нужно указать локальный адрес (относительно корня сайта) уже загруженного изображения.
Но в csv поставщика значений локальных путей к /storage/photo/original... не будет. Возможно имя изображения из архива с изображениями, возможен адрес сайта, в особо приятных случаях возможно совпадение имени изображения с артикулом. Но это нам ничего не даст

Вот и получается, что в readyscript нет способа импортировать комплектации с изображениями.
А это дикий косяк, я считаю. Но к нему ещё каждому надо будет прийти...

Предлагаю создать возможность быстрой продажи для товаров, которые покупают в точке продаж без заказа.
Зачем делать функционал быстрой продажи, если есть списание в складском учете?
1.Кнопка быстрой продажи более логично, если она будет находиться рядом с обычным созданием заказа.
2.В быстрой продаже в отличие от списания со склада предлагаю добавить возможность онлайн оплаты (Тут предлагаю не регистрировать покупателя, а дать возможность указать e-mail для отправки ссылки на оплату, если оплата происходит не наличными) А если клиент уже существует, то дадим возможность указать этого клиента из списка зарегистрированных, и подставим его e-mail в быстрый заказ.
3.В быстрой продаже менеджеру нет необходимости заполнять лишние поля, которые будут тратить лишнее время на обработку заказа, когда клиент находится в офисе и покупает товары.
4.При сохранении быстрой продажи происходит создание документа "списание" и товар в нужном количестве списывается со склада.
5.При быстрой продаже также быстро выбираем склад, с которого спишется товар.
6.В быстрой продаже удобно формировать заказ, когда клиент находясь в офисе самовывоза набрал много товаров (Открываем быструю продажу, сканируем штрих коды или выбираем товары вручную) и корзина собрана.

Создав такой тип продажи, владельцы магазинов смогут удобно фиксировать все продажи магазина в админке.
Дополнительно предлагаю разработать что то типа общего Z-отчета по всем продажам магазина за текущую смену.

В прикрепленных файлах несколько скриншотов как я это вижу.

При массовом редактировании товара нам необходимо добавить группу товаров в другие категории.
И мы забываем поставить галочку "Сохранить имеющиеся ранее категории".
При этом удаляется привязка товаров к старым категориям.

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

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

***
Это же так просто сделать, а скольких убережёт от потерь
/modules/catalog/view/form/product/mexdir.tpl
<input type="checkbox" checked name="xdir[notdelbefore]" value="1">