# Отключение ограничения операций по колонкам дополнительных параметров

Документ отвечает на вопрос «пользователи больше не могут фильтровать и сортировать по колонке дополнительного параметра — как вернуть прежнее поведение». Внутри: из-за чего операции пропадают, где включается настройка и что в ней написать, что меняется для пользователей, что остаётся как было, и технические подробности для инженеров и поддержки. Как ограничение работает по умолчанию — [business.md](https://help.1forma.ru/domains/grids/business.md), раздел про фильтр, поиск, сортировку и группировку по параметрам с ограничением доступа.

## Когда это нужно

В категории у колонки дополнительного параметра может быть настроен доступ: по матрице доступа, по пакетной SQL-функции или по статусу задачи. Пока такой доступ настроен, пользователь, который не читает значения параметра, по этой колонке не может ни фильтровать, ни искать, ни сортировать, ни группировать, ни смотреть итоги, а список значений фильтра ему не выдаётся. Сообщения об ошибке при этом не появляется — условие просто не применяется, и со стороны это выглядит как «пропал фильтр по дате» или «не выбирается справочник».

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

## Что такое «площадка»

Площадкой в документации называют вашу установку 1Формы целиком: сервер приложения и его базу — то, чем пользуются все сотрудники организации. Это не отдельная категория и не отдельный портал, а вся система на вашем сервере. Инженеры и поддержка называют эту настройку рубильником площадки: включили — и ограничение снято везде.

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

## Где включается настройка

Настройка живёт среди кастомных настроек приложения. Откройте раздел администрирования с ними — Администрирование → «Кастомные настройки приложения» (форма `custom-settings`) — и задайте ключу:

- **Ключ:** `GridColumnOperationRestrictionsDisabled`
- **Значение:** `true`

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

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

Чтобы вернуть прежнее поведение, задайте ключу любое значение кроме `true` или удалите строку настройки.

## Что меняется для пользователей

После включения настройки по колонкам с настроенным доступом снова работают:

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

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

## Что остаётся как было

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

Также не меняются:

- колонки параметров без настроенного доступа и обычные колонки;
- таблица без выбранной категории;
- права доступа к параметрам, их настройка в категории, расчёт прав и смарт-доступ;
- карточка задачи, старый интерфейс таблицы и печатные формы.

Заголовки групп, список значений фильтра и итоги при включённой настройке показывают реальные значения. Это следствие отключения ограничения операций, а не снятие прав на значение: в этих выдачах значения и раньше не маскировались.

## Как проверить, что настройка применилась

Проверяйте на категории, где есть три колонки дополнительного параметра: с матрицей доступа, с пакетной SQL-функцией и с настройкой «Доступ зависит от статуса» — так, чтобы у вашего пользователя в части состояний чтение было закрыто.

1. До включения настройки: по колонке с матрицей доступа фильтр не применяется, список значений не выдаётся; по колонке с доступом по статусу фильтр работает, но сужается по доступным состояниям.
2. Включите настройку и обновите страницу: фильтр, быстрый поиск, сортировка, группировка, итоги и список значений доступны по всем трём колонкам, сужения по состояниям больше нет.
3. Проверьте закрытое значение: в ячейке, в карточке задачи и в выгрузке в Excel оно по-прежнему не показывается.
4. Верните настройке прежнее значение или удалите строку: поведение возвращается к прежнему.

## Технические подробности

Настройка хранится строкой в таблице `dbo.SettingsCustom` с пустым `UserId` — то есть на уровне площадки, а не пользователя. Включающим считается единственное значение `true`: сравнение идёт после отсечения пробелов и без учёта регистра. Константа ключа — `CustomSettingKeys` в проекте `Valhalla.Integration`.

Читает настройку один общий класс `GridColumnOperationRestrictionSwitch` в `TCDataAccess/Caching/InMemory/`: и `Valhalla.Services`, и `TCClassLib` ссылаются на `TCDataAccess`, поэтому общий читатель живёт там — иначе часть путей, включая пакетный путь итогов, настройку не увидела бы. Скоуп контейнера подключается при его сборке, а до подключения настройка считается выключенной. Значение берётся из кеша настроек узла, снимка на запрос нет; сбой чтения глушится и даёт «ограничение работает», причём в журнал такой сбой не пишется — если ожидаемого эффекта нет, это первое, что стоит проверить.

Перехват стоит ранним выходом в четырёх местах: `ExtParamAccessControlHelper` (ограничение операций и сужение по состояниям), `ExtParamsInSubcatEntityService` (список ограничений), `ColumnFilterValuesAccessService` (перечень значений по источнику) и `ColumnSortingService` (ветка сортировки, вызывающая критерий напрямую). Через них гаснут все потребители критерия: конфигурация колонок, фильтр и быстрый поиск, сортировка, группировка, перечень значений лукап-колонки, сужение по состояниям и итоги; таблицы выбора лукапа и мультилукапа закрываются тем же резолвером на своей стороне.

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

Отдельно про перечень значений по источнику (`data-for-column`): при выключенной настройке перечень сужается по правам пользователя, а при включённой значения по источнику, сопоставленному с колонкой параметра, отдаются без такого сужения. Это самая широкая часть эффекта настройки, и она заказана вместе с ней: отключается ограничение операций, а не проверка доступа к данным. Маскировка значений в ячейках при этом сохраняется, а отказ по источнику, не сопоставленному ни с одной колонкой, остаётся.