Артем Полторанин

5 пользователей от одной компании - под такой сценарий у нас нет готовых решений. У нас в архитектуре системы предполагается: 1 пользователь = 1 компания. Фактически у вас заказ привязывается к 5 разным пользователям. Просто технически заказ никак не связан с ИНН, поэтому отдельного поиска по ИНН у заказа быть не может в системе. ИНН - это свойство именно пользователя. ---- Вы можете к нам обратиться за доработкой, мы можем предложить сделать для вас кастомный фильтр в заказах.

Это не баг. Статусы - это как папки. Сначала переходм в папку, а потом в ней фильтруем. При смене папки, фильтр сбрасывается, у нас такая логика во всех разделах. т.к. потенциально, для разных статусов (папок) могут быть различные фильтры.

Нет, мультиязычность контента пока не планируем. Пока мы придерживаемся модели мультисайтовость + интернационализация, т.е. для каждой языковой версии нужно создать мультисайт. Мы много раз обсуждали и изучали вопрос мультиязычности контента внутри ReadyScript. С технической стороны - это будет означать значительное замедление работы системы (даже тех, кто будет использовать 1 язык), так как каждая сущность должна быть разделена в БД на 2 таблицы, вместо одной, чтобы хранить в одной таблице основные сведения, в другой сведения для конкретного языка. Соответственно все выборки обрастут JOIN'ами и нагрузка на БД повысится. Мультиязычность - означает трансграничную и интернациональную торговлю в большинстве случаев, а здесь возникает огромное поле смежных задач, связанных с реализацией полноценной мультивалютной торговли, интернациональных доставок, экспортных ограничений и многое другое. Да и мультиязычность контента - это то, что пронизывает абсолютно все подсистемы, поэтому об этом можно думать только при старте разработки системы, либо при очень огромных вложениях в тотальную смену архитектуры. Наверняка я разочаровал кого-то своим ответом, но сложность этой задачи должна быть понятна и пока ожидать ее решения не стоит.

Добрый день! В ближайшем обновлении будет добавлена поддержка ссылок с RuTube и VK Видео.

Поло Арт, нормальная мультиязычность не должна создавать новые таблицы при добавлении языка. Хранить переводы всех сущностей (сущностей сотни) в одной таблице мы тоже не считаем удобным и технически правильным подходом. Наиболее классическая с технической точки зрения мультиязычность контента есть в openCart, там каждая сущность представлена в двух таблицах product, product_lang, cost, cost_lang, property, property_lang, ..... В этом случае у вас создается объект в основной таблице, например, product, а в таблице product_lang создаются 2 технические колонки product_id, lang_id, а дальше колонки с мультиязычными полями.