Так как тема ушла в оффтоп и неконструктив, я её закрыл. Но некоторые важные моменты прокомментировать могу.
Ещё момент: как только я впервые в теме ответил, то сразу попросил поддержку скинуть сюда diff-файл с фиксом из 4.16.1. Хотя тема закрыта, но @Asya всё равно сможет в ней ответить.
Логика настройки “Показывать товары, которых нет в наличии” для вариаций такая же, как для списка товаров на витрине:
- Если настройка включена, покупатель может попасть на страницу такого товара.
- Если настройка не включена, покупатель не может попасть на страницу такого товара (только по прямой ссылке).
Разница только в том, что в случае с вариациями он видит, что другие варианты тоже возможны. Т.е. клиент сразу понимает, что в наличии и не в наличии.
То, что при включенной настройке “Показывать товары, которых нет в наличии” отсутствующие вариации оставались неактивными — это баг. Его исправили.
Всё остальное — это запрос на изменение функциональности. Мы за ними следим, но не можем по каждому запросу обещать “исправим за 45 дней” (как с багами). Поэтому такие понятия чётко разграничиваем. В запросах на функциональность нужно намного больше планировать и разрабатывать.
Понимаю вас. Могу только сослаться на свой прошлый ответ в другом баг-репорте, почему так. Баги помечаются исправленными после того, как исправление:
- готово;
- протестировано;
- точно попадёт в одну из будущих версий (скорее всего в самую ближайшую).
Если менять этот подход и помечать баги как исправленные после выхода этой версии, то работа на баг-трекере точно усложнится и замедлится. А польза при этом будет сомнительная.
Обычно это означает, что обращаться лучше в поддержку в Help Desk (они помогают, если модификация небольшая), либо за доработкой под себя (для вашего случая, насколько я помню, была таблица размеров).
При разработке новой функциональности для массового продукта (а ваш запрос — именно про новую функциональность) времени нужно больше. Так как нужно проработать максимум возможных сценариев — как это будет работать в разных магазинах, насколько это повлияет на скорость загрузки страницы товара, и т.д. и т.п.
Поэтому доработки для конкретного магазина делаются быстрее — там можно принимать такие решения, которые в массовом продукте принимать нельзя.