Идеи пользователя 17090

Простейшая штука, а так была бы полезна.

В коде компонента вывода списка элементов (например, catalog.section), в месте, где происходит обращение к БД на выборку элементов, сливаются воедино два фильтра - тот, что задан в коде компонента, и внешний, который может быть задан разработчиком без влезания в код.

Сейчас это выглядит так:
$arrFilter - это преднастроенный в коде компонента фильтр.

Такая последовательность (ввиду логики работы array_merge) не позволяет переопределять параметры фильтрации, заложенные в коде компонента. Они всегда будут перезаписывать то, что пришло извне!

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

А дело-то всего лишь в последовательности переменных...

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

Мы сталкиваемся с необходимостью такой привязки почти в каждом проекте. Думаю, что остальные - тоже. В большинстве случаев - забиваем, и используем обычное числовое поле, куда контент-менеджер указывает ID раздела. Но это дико неудобно.

Может все же решить эту проблему? Ведь это так просто - создать еще один тип свойства, и хранить его значение не так, как в текущем (с проблемами архитектуры), а просто как числа - ID разделов...

Уже очень давно существует проблема, а обновления так и не появляется.

При ответе в тикете техподдержки, возможно прикрепление файлов. Ссылки на прикрепленные файлы уходят автору обращения в теле письма. При попытке зайти по этим ссылкам у большинства наших клиентов (так как они в основном не пользуются личным кабинетом, а работают путем переписки по e-mail) открывается белая страница с красной надписью "Файл не найден". Это вводит людей в ступор.

Понятно, что человек не авторизован, и скачивать файл ему не положено. Но просто писать "Файл не найден" - тоже не выход.

Пожалуйста, сделайте переброс на форму авторизации, после которой файл сразу начнет скачиваться.

Коллеги!

Пожалуйста, исправьте явные недоработки в стандартном шаблоне bitrix:sale.order.ajax (по состоянию на 01.06.2016):

• Нельзя редактировать состав заказа, хотя всё в интерфейсе указывает на такую возможность (пользователю предлагается его "Изменить", но нажатие данной ссылки ничего толком не дает)
• Некорректная, сбивающая пользователя с толку, работа поля "Скидка" в правой плавающей части итоговой информации по заказу. Пример: мы настроили скидку на доставку при заказе от 10000 руб. Если заказ меньше 10000 руб., то доставка стоит 1000 руб. Получилось: "Товаров на 10000 руб. (зачеркнуто, например, 15000 руб. - "старая цена"), Скидка: 1000 руб., Доставка: 0 руб., Итого: 10000 руб.". Абсолютный бред.
• Подключение бутстрапа, который переопределяет некоторые базовые стили шаблона. Например, цвет ссылок при наведении курсора, дизайн цепочки навигации, если она названа классом breadcrumb...
  

Ситуация:

• В поддержку написал незарегистрированный пользователь (или он не авторизован на сайте). Написал на почту, которая автоматом стала обращением в ТП
• Сотрудник ТП ответил ему что-то, и приложил файлы
• Человеку на почту пришло письмо со ссылкой для скачивания файла (ради него он и обращался в ТП), но скачать его он не может! "Файл не найден"
  

Как нужно сделать:

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

Добавить возможность изменения цвета "лампочки" тикета (то есть, требуется ли от автора ответ, или от техподдержки). Сейчас если вдруг при написании промежуточного ответа забываешь поставить галочку "Не изменять статус обращения" - потом надо лезть в изменение этого сообщения и т.д. А если несколько сообщений написал - надо во все лезть и править...

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

Реализовать возможность в настройках модуля инфоблоков запретить пользователю менять дизайн форм, заданный администратором (при разработке).

Реально, очень важная вещь! Сейчас если какой-то пользователь-контент-менеджер случайно решил "поиграться" с шестереночкой справа вверху формы редактирования элемента инфоблока и нажмет "сохранить" - все дальнейшие административные изменения этой формы никак у него не отражаются! Да и вообще - не нужна эта функция простым смертным!

Наткнулся на необходимость кастомизировать шаблон "Персональных рекомендаций" (BigData).

Господа... Ну это же капец! (если выражаться без мата) Это еще бОльшая помойка, чем шаблон оформления заказа!

Такими темпами Битрикс скоро вообще будет не под силу кастомизировать! Остановитесь, коллеги! Наймите нормальных фронтендеров. Задача - делать нормальную верстку, делать фронтенд, который можно кастомизировать, не будучи семи пядей во лбу!

Изначально моя идея была простой - скопировать шаблон компонента рекомендаций, в нем всю имеющуюся муть удалить, взять ID "рекомендуемых товаров" из $arResult и подставить их в фильтр компонента catalog.section. Ведь по сути в этих "персональных рекомендациях" полностью дублируется функционал списка товаров. Зачем? Где же забота о масштабируемости, оптимизация разработки, исключение дублирования? Понадобится что-то добавить в шаблон списка - придется править и рекомендации? Это нормально? Поэтому решение казалось логичным.

Но не тут-то было. Благодаря мегазамудренному клубку JS под соусом "композита" (который нужен 5% сайтов) я сижу второй час и не понимаю, почему даже засунув весь шаблон данного компонента в невидимый div - $arResult становится пустым...

Суть решения проблемы: сделать компонент или метод API, который бы просто возвращал массив ID рекомендуемых товаров (желательно, в PHP)

Понимаю, в общем-то, из-за чего такой ужас получился - из-за того, что данные надо выцеплять асинхронными запросами посредством JS, ибо иначе будет тормозить и т.д. Но товарищи - сейчас получился монстр...

PS. Я работаю с Битрикс уже 10 лет, не подумайте, что я новичок. Все сказанное выше - моё мнение. Если кому-то кажется текущая реализация "нормальной" - могу только поздравить их: эти люди обладают невероятной эрудицией в программинге и нестандартным мышлением.

Сделать нормальный шаблон, который бы подвергался кастомизации без взрыва мозга и приема тяжелых антидепрессантов... Не, ну серьезно - вы сами видели свой код?!?!?!?!??! Кто-нибудь вообще понимает как это все еще как-то работает? ))))

Зачастую при выполнении "Проверки сайта" выдается ошибка, что кодировки таблиц БД отличаются от нужной. И почему-то эти ошибки "не подлежат автоматическому исправлению", хотя по сути требуется выполнить SQL-запрос на каждую такую таблицу.

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