Прошу поддержать мою идею! Так как данное пожелание Битрикс не может реализовать уже больше 11 лет предлагаю им несколько упростить задачу.
Через многоязычность интернет магазина пришлось сделать под каждый язык отдельный торговый каталог.
После введения складского учета хотелось бы как-то вести учет товаров с разных торговых каталогов.
При создании приходной накладной нужно, чтобы учитывалась возможность добавления товара в несколько торговых каталога. Нужна некая связка, чтоб система понимала, что в разных торговых каталогах один и тот товар и соответственно подсчитывала его остаток учитывая продажи/резерв с разных каталогов и прописывала в товар общий остаток.
public static function set($moduleId, $name, $value = "", $siteId = "")
Сейчас опшен можно записать/получить для указанного $siteId. Было бы ещё лучше если добавили группу пользователя. Например для группы_1 сайта_1 можно было сохранить одну минимальную сумму для заказа, а для группы_2 сайта_1 другую. Или показывать "мою фичу" только на сайте_3, для группы_1.
Предложение касается строки фильтра: "?PROPERTY_CML2_ARTICLE"=>$acat При помощи этого фильтра отфильтруются элементы, у которых $acat является подстрокой строки "PROPERTY_CML2_ARTICLE".
А отфильтровать в другом направлении, чтобы значения "PROPERTY_CML2_ARTICLE" могли быть подстроками $acat невозможно.
В стандартном функционале есть возможность создания в облаке Битрикс резервной копии по расписанию через облачный сервис "1С-Битрикс". Бывает нужно при нехватке ресурсов на хостинге. Иногда полезно сделать такую копию разово вне очереди по нажатию на кнопку. Также, полезно добавить возможность скачивания резервной копии с Облака.
Облачный сервис - это планировщик, аналог cron. Для тех случаев, когда настройка cron недоступна. Для разовой резервной копии есть соответствующая страница в браузере. Загрузка копий из облака делается через restore.php.
Вопрос актуален уже несколько лет. По причине какого-то глобального архитектурного косяка, при настройке свойства инфоблока "Привязка к разделам" система не позволяет выбирать текущий инфоблок, для которого это свойство заводится.
Мы сталкиваемся с необходимостью такой привязки почти в каждом проекте. Думаю, что остальные - тоже. В большинстве случаев - забиваем, и используем обычное числовое поле, куда контент-менеджер указывает ID раздела. Но это дико неудобно.
Может все же решить эту проблему? Ведь это так просто - создать еще один тип свойства, и хранить его значение не так, как в текущем (с проблемами архитектуры), а просто как числа - ID разделов...
Как писал ранее, highloadblock еще остаются "сыроватыми". Столкнулся с таким моментом при создании: делаю обязательным текстовое поле, создаю запись, затем стираю текст в этом поле и без проблем сохраняю. Складывается ощущение, что оно перестает быть обязательным.
Очень частная задача. В подавляющем большинстве случаев резервная копия делается чаще. Я бы рекомендовал делать регулярное резервное копирование только базы средствами битрикса в наше облако. К сожалению, случаются ситуации, когда на хостинге теряются резервные копии. В этом случае ваша актуальная база данных будет в сохранности.
Идея разрешить и поощрять пользователей создавать документацию. Сейчас, чтобы почитать по d7 нужно читать курсы, потом еще гуглить сайт, форум/блоги. Из-за этого много информации которую ищешь, просто не читаешь. А это сильно тормозит саморазвитие и увеличение навыков.
Если весь опыт будет в одном месте, уверен это очень сильно всем поможет.
Чтобы пользователи размещали именно в документацию, нужно их стимулировать бонусами. Размещение информации - премодерируемое.
Создать свод правил по которым нужно размещать документацию. В документации создать перелинковку с курсами.
Чем для этой цели не устраивают вас комментарии к доке и страницам курса? Под каждой из страниц есть форма для добавления, даже в новой доке по D7. Пишите, никто же не против.
Бонусы - никогда не были против раздачи баллов по партнёрской программе. Более того, давали и раздавали такие бонусы за реальную помощь. Деньгами - это уже сложнее. Не уверен, что такая идея получит поддержку у руководства.
Свод правил - не нужен, не нужно вам забивать голову стилями, оформлением и так далее. Просто выдайте то, что считаете нужным. Мы сами и отсеем и оформим.
Если нет страниц, куда надо добавить, просто шлите информацию на мой e-mail и она отобразится в курсах, документации.
Перелинковка доки и курсов - есть, может не везде и не туда, это возможно. Но для этого и создано поле для комментариев. Пишите, добавим линки.
Для донесения полезной информации до нас есть все инструменты. Вопрос в самой информации. Помниться, после того как появилось поле для комментариев, мы создали по просьбам пользователей пустые страницы в доке по неописанным методам, чтобы была возможность добавлять комментарии по этим методам. Помниться даже наполнили с десяток страниц. Но и всё, сейчас дело заглохло.
Идею с голосования снимаю, не надо придумывать какие-то дополнительные механизмы.
Нехватает информации о результате проверки контроля целостности напротив каждого бекапа в списке бекапов. Сейчас если в процессе бекапа закрыть браузер то бекап будет, но неполный, но об этом можно только сделать предположение...
Не закрывайте браузер до появления сообщения об успешном создании бэкапа. Такое действие нарушит целостность при любой пошаговой операции: импорт инфоблоков, восстановление структуры таблиц и т. д.
Удивительно что еще не реализовано и вроде как никто не предложил такую идею. А такая возможность была бы очень часто полезной.
Сейчас подраздел может лежать только в одной родительской категории, а элементы - могут быть привязаны к нескольким категориям. Вот хотелось бы, чтобы и разделы можно было привязывать к нескольким родителям...
Сейчас при выводе массива элементов выводится только один раздел к которому принадлежит элемент (минимальный SECTION_ID). Приходится либо ограничивать привязку элемента только к одному разделу, либо делать дополнительное обращение к БД (CIBlockElement::GetElementGroups).
Конечно, если это не притормозит GetList в целом.
Хм, присмотрелся внимательнее, думаю предложение можно удалить.
Несколько раз сталкивался с ситуацией, когда надо связать функционал какого-либо модуля с инфоблоками, и проще всего это сделать через обработчики событий, но тут мы можем столкнуться с зацикленностью, и вот в этой ситуации сабж. бы сильно помог.
Артем, этот вопрос рассматривался неоднократно и решение давно выработано. Отключение событий невозможно - сам продукт их использует. Как избежать зацикленности - тоже известно.
Ребят это сайт идей, у вас же Баг, причем нужен сценарий воспроизведения и лучше в Техническую Поддержку его написать, чем сюда, он быстрей будет выполнен.
Очень часто возникает ситуация что стандартная проверка сайта не показывает отсутствие необходимых модулей для установленных на сайте решений из МП.
Предлагаю сделать доп проверку и чеклист при публикации решений а также на основании этого чек листа в стандартной проверке добавить еще одну на наличие необходимых модулей для решений МП.
и желательно в помощи выводить сразу команды инсталляции библиотек для ВМ Битрикс.
Загрузка копий из облака делается через restore.php.