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

Проблема:

Сайт работает с двумя БД: локальной (в ней новости, данные пользователей, прочая обычная информация) и удаленной (внутренняя БД клиента с конфиденциальной информацией, которую недопустимо хранить на сайте).

Работу с внешней БД организовали через подключения d7, но монитор производительности никак не регистрирует такие запросы и не позволяет узнать, есть ли среди них проблемные. А это очень бы не помешало.

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

Страница админки "Управление модулями" не самая популярная - о ней вспоминают пару раз за проект (в начале или в конце удаляют все лишние модули, время от времени переустанавливают вновь понадобившиеся). Но это не повод делать ее неудобной. В чем неудобство, спросите Вы?

На современных широких мониторах это выглядит вот так (http://shot.qip.ru/00dxgE-116IxPIkQC/). Название модуля - слева, а статус (установлен/удален) и кнопки справа. Во время массовой установки/удаления это вызывает невероятный дискомфорт - нельзя одним взглядом охватить сразу и названия модулей и их статусы. Приходится сжимать окно браузера до смешных размеров (http://shot.qip.ru/00dxgE-116IxPIkQD/), но куда лучше было бы изменить макет этой страницы. Прошу задуматься об изменении структуры этой страницы. Что в первую очередь волнует пользователей здесь? Название модуля, его статус и кнопка (почему бы их не объединить?). Потом уже описание, версия, дата обновления.

Хочется событие OnBeforeSetUserGroup
А то на момент OnAfterSetUserGroup уже никак не узнать, в каких группах пользователь был раньше.

Зачем это нужно

Да вот прямо фрагмент из ТЗ:

По факту включения пользователя в группу, пользователю на e-mail, указанный при регистрации, должно отправляться почтовое уведомление с информацией о включении в группу.

При настройке обмена товарами и заказами между ИМ и 1С'кой часто сталкиваемся с проблемами. Решаем их всегда одинаково: при завершении импорта, пока в папке еще лежат XML, копируем их в upload/xml/текущая дата и время/

И тогда пусть 1С сделает хоть 100 выгрузок, у нас останутся на сервере для "расследования" все ее XML'ки
Очень хотелось бы, чтобы такой механизм копирования файлов обмена с 1С был встроен в продукт изначально.

Дано:
Интернет-магазин, обмен товарами, заказами с 1С через XML (стандартно). Создан десяток свойств заказа (типичные свойства - телефон, почта, ФИО, адрес и т.п.)

Проблема:
Очень редко в выгрузке заказов наблюдаются заказы без свойств. Такой проблемный заказ - 1 на 2000 заказов. Расследование показало, что этот XML формируется в ту же секунду, что и оформление заказа.

В ТП Битрикса задан вопрос (тикет 710508 ):
Ответ сотрудника ТП:
Безобразие. В 1С могут улететь заказы без свойств.

Идея:
Защитить транзакциями оформление заказа или добавить некий булевый признак к заказу "годный к выгрузке" и выставлять его только после оформления заказа, прикрепления товаров и всех свойств.

Речь пойдет о методе
https://dev.1c-bitrix.ru/api_help/main/reference/cfile/resizeimageget.php

Метод мощный и удобный. Но недавно столкнулись с интересной проблемой на проекте. Контент-менеджер знал, что баннеры будут урезаны и сразу подготовил картинки нужного размера. При этом картинки весили по 500 кб. В настройках главного модуля стояло сжатие с качеством 95%, но, т.к. картинки были уже нужного размера, сжатия по размеру и качеству не произошло и на главной странице остались картинки по полмегабайта весом.

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

,Стоит добавить параметр FILTER_NAME в news.detail и catalog.element, по аналогии с catalog.section - чтобы можно было задать дополнительные фильтры на детальной странице товара. На данный момент, если нужно скрыть товары из каталога по сложной логике, требуется сделать GetList-фильтр для catalog.section, а в result_modifier, template, component_epilog детальной страницы писать дополнительный запрос/анализировать $arResult элемента. Оба варианта плохи - в первом случае будут дополнительные запросы, а во втором потребуется переписать код GetList-фильтра (дублирование кода)

Пример:
$GLOBALS["arrFIlter"] = array("PROPERTY_HIDDEN" => "Y");

result_modifier.php, template.php

if ($arResult["PROPERTIES"]["HIDDEN"]["VALUE"] == "Y")
{
// Заморочки с организацией 404-ой страницы.
}

Новый autoload с поддержкой namespace в модулях зверски удобен. Было бы здорово подружить его и с папкой php_interface, в которой обычно лежит вся кастомная логика сайта.

Чтобы классы, например, вида Bitrix\Local\Tool\Seo искались в /bitrix/php_interface/lib/tool/seo.php и /local/php_interface/lib/tool/seo.php

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

Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.

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

Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.

В компоненте импорта торгового каталога из 1С (catalog.import.1c) есть удачные события: OnBeforeCatalogImport1C и OnSuccessCatalogImport1C.
Очень хотелось бы увидеть аналоги в компоненте импорта справочника (catalog.import.hl).

Коллеги, добрый день!

Есть такая технология - OpenSearch. Если сайт ее поддерживает, то посетителям будет предложено добавить сайт в список поисковых систем браузера и можно будет осуществлять поиск сразу по нужному сайту.

Краткое описание технологии: http://habrahabr.ru/post/65540/

Предлагаю для сайта https://dev.1c-bitrix.ru/api_help/ (документация для разработчиков) сделать такую вещь. Там работы на 5 минут.

http://shot.qip.ru/00dxgE-516IxPIezj/

Обладатели Интернет-Магазинов знают про отличный инструмент "Профили импорта". 1 раз настроили - n раз пользуемся. Очень хотелось бы увидеть такой механизм и на странице резервного копирования. И не нужно слов про регулярное копирование - там профиль только один.

У нас в веб-студии есть определененный стандарт: все обработчики хранятся в модулях в папке lib/eventhandlers/<код модуля, чье событие обрабатывается>.php
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin

Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.

Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?

Не знаю, как в других фирмах, а у нас по утрам корпортальчик полон сообщений вида "опоздаю на 30 минут", "буду в 11", "сломался лифт, буду в обед" и т.д. кто во что горазд. Люди в большинстве своем пишут с телефона. Было бы намного удобнее, если бы в Б24, как в десктопной версии, так и в мобильной, была бы кнопочка "предупредить об опоздании", которая в простейшем случае позволяла бы просто ввести время опоздания. А на выходе бы получалось некое стандартное сообщение в ЖЛ вида "Сотрудник Мистер Икс опаздывает и будет в чч:мм".

Выглядело бы примерно так
http://shot.qip.ru/00dxgE-616IxPIajB/

P.S. Впоследствии можно было бы даже ввести автоматический учет - опозданий и прогнозов - ведь время, когда он пришел в офис мы можем узнать через время начала рабочего дня сотрудника.

Раз уж переходим к ООП в компонентах, то давайте делать и следующие шаги в этом направлении. Похоронили component.php, покусимся и на .parameters.php, .desсription.php. Ведь фразы вроде “Есть возможность наследования компонент” не выдерживают критики. Да, когда нужно создать похожий компонент, мы копируем не три файла, а всего два (+ не забываем про шаблоны). Почему бы не сделать в CBitrixComponent два новых метода - getDescription и getParameters, которые бы заменили эти старые добрые процедурные файлы?

P.S. К слову о шаблонах - почему бы не давать компоненту пользоваться шаблонами родительского компонента?

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

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

Вспомните компонент iblock.element.add.form, который сохраняет только те свойства, которые указаны в настройках. А так же вспомните, что он позволяет выбрать только простые поля, а вот привязку к элементам инфоблока, например, не умеет. Чтобы разрешить эту проблему каждый раз приходится его кастомизировать и добавлять в список нужный вам тип полей.
Мне могут возразить - есть же параметры шаблонов, туда можно добавить все, что угодно! Да, можно, но только добавить, а не изменить.
Если бы такое событие было, то можно бы создать обработчик события, и для компонента iblock.element.add.form для всех шаблонов разом добавить поддержку новых типов данных.

P.S. Поможет в реализации идеи http://idea.1c-bitrix.ru/ability-to-hide-the-component-settings-when-you-configure/

Идея:

Сделать возможность более тонкой настройки разделов в инфоблоках, как минимум - настройка обязательности полей для разных уровней. например, на каком-то уровне картинка является обязательной, а на другом - ее в принципе не может быть.
Как максимум - дать возможность настройки формы редактирования для разделов разных уровней, чтобы при добавлении раздела уровня 1 показывалась одна форма, раздела 2-го уровня - другая и т.д.

Кому и зачем нужно:

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