В разных местах по разному!
Не удобно.

-почта. https://prnt.sc/onrg3o  нет шестеренки, нет сортировки
-срм. https://prnt.sc/onrgfz непо всем полям возможна сортировка
-список исключений. https://prnt.sc/onrgrt  мало полей
-он же https://prnt.sc/onrh2k  нет выбора количества элементов на странице, мало груповых действий
-где есть выбор количества элементов https://prnt.sc/onrhf9  нет параметров 200, 500 как в 1С:Битрикс


Хорошо бы чтобы все было в одном стандарте.

Есть раздел документации "Параметры компонента" https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=2132 в котором до сих пор ничего не говорится о возможности добавлять дополнительную переменную $arComponentParameters для добавления параметров шаблона.

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

Поэтому предлагаю:
1. Добавить описание переменной $arComponentParameters в документацию
2. Создать возможность добавления групп параметров из шаблона (Я уже не говорю о переопределении, а хотя бы добавление).

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

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

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

Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер.
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.

Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).

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

UPDATE 2015-04-01

Теоретическое обоснование и рекомендации от известных разработчиков:

• http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
• https://github.com/paulirish/html5-boilerplate/wiki/cachebusting/e58c07be9f0a43da08e766b21514f81ece24fa17
• http://webassets.readthedocs.org/en/latest/expiring.html#expire-using-a-querystring
• Application cache

  Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.

  https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache#Gotchas
  

Реализации:

• В Apache https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess#L982-L998
• В Nginx https://github.com/h5bp/server-configs-nginx/blob/master/h5bp/location/cache-busting.conf
• Rails Asset Pipeline http://guides.rubyonrails.org/asset_pipeline.html#what-is-fingerprinting-and-why-should-i-care-questionmark
• Модуль Web Optimizer для 1С-Битрикс, многие идеи из которого перешли "в коробку" https://dev.1c-bitrix.ru/community/blogs/rsv-dev/1732.php
  

Первые попашиеся "правильные" сайты:

• Все проекты TM (http://habrahabr.ru/, http://megamozg.ru/, http://geektimes.ru/ и т.д.)
• https://twitter.com/
• https://www.facebook.com/
  

Font-Awesome планирует в 5-й версии перенести параметр в название файла шрифта https://github.com/FortAwesome/Font-Awesome/issues/5231 и https://github.com/FortAwesome/Font-Awesome/issues/3286

Сейчас, для того чтобы заставить страницу работать в композитном режиме нужно, как минимум, залезть в шаблон каждого компонента и добавить строчку


Когда таких компонентов много — процесс затягивается... А бывает , что просто приходится умышленно копировать какой-нибудь bitrix:socserv.auth.form к себе в шаблон сайта, ради того, чтобы всё остальное заработало...

Слишком много лишних действий. Можно и нужно сделать проще...

Например, ко всем компонентам добавить параметр a la "CACHE_TYPE":
"COMPOSITE" => "ALLOW" | "USE" | "SELF" | "DENY"
И рассмотреть возможные кейсы:

1. Компонент «разрешает» работать остальным;
2. Компонент сам работает в композитном режиме*;
3. На усмотрение разработчика (разработчик сам правит шаблон компонента и расставляет динамические/статические области);
4. Компонент запрещает «всё и всем»;
   

*Предполагает, что система сама оборачивает шаблон компонента в:

 

Сейчас он доступен, только в bitrix:search.form:





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

В других компонентах (например, bitrix:sale.basket.line или bitrix:catalog он не доступен).

Добавить в компонент bitrix:catalog.section.list возможность указать в параметрах максимлаьное число выбираемых разделов (например, я хочу вывести первые 10 разделов первого уровня), и возможность задавать параметры постраничной навигации.

Так же хорошо бы реализовать идею с фильтрацией в компоненте bitrix:catalog.section.list
http://idea.1c-bitrix.ru/in-the-component-bitrixcatalogsectionlist-add-support-filter/

Предлагаю добавить права на доступ к редактированию параметров компонента для групп пользователей.

Чтобы дать доступ, например, группе "контент-менеджер" редактировать только определенные параметры компонента (а не все сразу).

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

Если оставить групе права менять только менее значащие параметры (настройки постраничной навигации, цветовую схему, количество элементов на странице или настройки вывода свойств), то будет намнго удобнее и безопаснее.

Добавить поддержку параметра REFRESH => "Y" в настройках параметров компонента (.parameters.php) для свойств с типом "Список" (LIST).

В компоненте bitrix:catalog.section в настройках параметров поле для выбора раздела сделать в виде выпадающего списка разделов выбранного инфоблока:


При этом, возможность ввода дополнительных значений желательно оставить.

Добавить событие при построении дерева параметров компонента (чтобы можно было модифицировать параметры стандартных компоненов).

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

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

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

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

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

Например, я использую компонент bitrix:catalog, и потом отдаю его в продакшен под управление клиенту, но мне нужно скрыть из него ненужные параметры, чтобы не навредить (например, настройки ЧПУ, которые всё равно дублируются в инфоблоке, или типы цен). И оставить только самое нужное (например, кол-во элементов на странице, параметры сортировки, выбираемые свойства, и еще пару мелочей).



Зачем клиенту лицезреть эту простыню из стандартных параметров, 90% из которых задаются один раз, разработчиком, и лучше чтобы он их менял, а контент-менежер или клиент - их не видели, и если нужно - могли менять через код (или галочку "показать все настройки";).

Многие любопытные клиенты с шаловливыми ручонками любят залезть в визуальном редакторе в настройки компонентов и что-нибудь там пощелкать. То есть хотелось бы иметь возможность скрывать параметры компонентов. Каким образом? Скажем, в файле .parameters.php шаблона компонента указывать (при программировании сайта), какие настройки оригинального компонента скрывать при редактировании с лица.

То есть, чтобы пользователь мог открыть параметры компонента, но отображались ему не все поля, а только те, которые мы ему оставим. Честно говоря, это полезно было бы и при разработке для программистов - когда компонент имеет несколько десятков параметров, становится сложно ориентироваться. А если бы механизм существовал - можно было бы скрыть те параметры, которые уже не будут меняться.

Пример 1:
на странице каталога размещен комплексный каталог и ID инфоблока не будет меняться никогда с вероятностью 90%, а клиенту это вообще не нужно в 100% случаев - так и нужно дать возможность скрыть эту настройку.
Настройки ЧПУ, кеширования - тоже избыточны для клиента. Оставим ему списки полей, какие где выводятся - и этого будет достаточно.

Пример 2 (VCS):
В проектах с git'ом или любой другой VCS в параметры компонента обычно передаются не ID'шники (которые могут быть различными на dev, stage и prod-серверах), а что-то вроде getIblockIdByCode("news";). Скрыть такое от глаз неподготовленного человека тоже полезно.

Добавить в настройку activity  Утверждение документа дополнительный параметр требовать комментарий при отказе:



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

Это позволит сэкономить время затрачиваемое на выяснение причин отказа по телефону или электронной почте.