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

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

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

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

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

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

Коллеги!

Вы внедрили замечательный механизм ORM, благодаря которому создавать свои сущности стало очень просто (с точки зрения программиста). Но раз вы разработали "стандарт" ORM для Битрикса, может, сделаете и набор стандартных компонентов для работы с ним (список записей, страница записи, добавление записи)? В том числе и стандартные страницы для админки со списком записей, фильтром, страницей редактирования записи.

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

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

Вспомните компонент 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-го уровня - другая и т.д.

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

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

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

Как решить:
Сделать галочку для свойств "Только для чтения", чтобы в админке нельзя было редактировать свойство, а только видеть его значение. У пользовательских же свойств это есть, давайте сделаем и для свойств элементов инфоблока.

А то после скачивания пятка бекапов с разных сайтов никак не понять, какой бекап с какого сайта. А если бы в начале названия бекапа значился домен, было бы намного удобнее.

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

Идея

Сделать обертку над функцией GetCurPageParam, которая бы автоматически удаляла из генерируемого урла такие параметры, как show_page_exec_time, bitrix_include_areas, clear_cache, и прочие стандартные переменные Битрикс.

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

Разработчик заходит на страницу и сбрасывает кеш через clear_cache. Весь кеш удаляется и генерируется заново. Если компоненты выводили ссылки с помощью GetCurPageParam, и там не прописано удаление переменной clear_cache, эта переменная попадает в ссылку и ее увидит каждый пользователь на сайте. Решения три
- сбрасывать кеш только в админке
- каждый раз писать, чтобы GetCurPageParam удаляла clear_cache
- сделать обертку над GetCurPageParam, которая будет это делать сама, и вызывать уже ее.