Видимость строк (RLS)

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

Откройте датасет — из списка Датасеты или по ссылке с виджета — и нажмите Видимость данных в верхней панели. Правила строк живут на вкладке Строки (RLS). Соседняя вкладка Колонки (CLS) закрывает поля целиком — см. Видимость полей.

Как складываются правила

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

Первое же правило закрывает данные всем остальным

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

Владелец датасета — не исключение. Заведите правило «город = Москва» и адресуйте его одному исследователю: он увидит на диаграмме «Выручка по категориям» три категории вместо четырёх и суммы вчетверо меньше. А создатель датасета получит пустой результат — без единого сообщения об ошибке.

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

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

Правило на таблице-справочнике не скрывает суммы

Проверьте, на какой таблице задано правило

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

На витрине «заказы + товары» правило по полю «Категория» таблицы товаров даёт такую картину тому, кому оно не адресовано: строк с названиями товаров нет, зато есть одна строка с пустыми названием и категорией — и полной выручкой по всем заказам, 134 683 500. Адресат правила видит своё и ту же лишнюю строку: 17 985 000 по своей категории плюс 116 698 500 «прочих».

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

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

Если поле-ограничитель есть только в справочнике

Частый случай: ограничивать нужно по категории товара, типу договора или филиалу клиента, а это поле лежит в справочнике, не в фактах. Обходных путей внутри правил нет:

Путь	Что получается
Правило «Список значений» на поле справочника	Строки справочника закрываются, но суммы по фактам остаются видны — случай выше
Правило «Выражение» на объекте-справочнике	То же самое: закрываются подписи, не агрегаты
Правило «Выражение» на таблице фактов со ссылкой на поле справочника ([products.category] = "Периферия")	Правило сохраняется, но выборка у адресата завершается ошибкой «field not found»: в выражении доступны только поля своего объекта

Рабочий приём один — перенести ограничитель в таблицу фактов: добавить в неё колонку с категорией, филиалом или типом договора при подготовке витрины. Вычисляемым полем датасета этого не заменить: правила видят только колонки объекта. Пока такой колонки нет, ограничение по полю справочника считайте нерабочим.

Порядок целиком — от учётной записи получателя до проверки чисел — разбирает Каждому свои данные.

Создание правила

Заводить и включать правила может владелец датасета и тот, кому выдано право администрирование на него; права «редактирование» для этого мало — управление доступом.

Нажмите Новое правило и заполните форму сверху вниз:

Поле формы	Что указать
Название	Понятное описание, например «Только свой регион»
Вид правила	Атрибут пользователя, список значений или выражение — см. таблицу ниже
Объект и Поле	Таблица датасета и её колонка, к которым применяется ограничение
Условие	Зависит от вида: имя атрибута, список разрешённых значений или само выражение
Кому адресовано	Кому правило предназначено — всем или выбранным пользователям и группам
Правило включено	Выключенное правило сохраняется, но в ограничение не входит

Вид правила задаёт, откуда берутся разрешённые значения:

Вид	Как работает
Атрибут пользователя	В условие подставляются значения атрибута учётной записи: поле IN (значения атрибута). У атрибута может быть несколько значений — тогда пользователь видит строки по всем из них. Атрибуты задаёт администратор в карточке пользователя; значения из внешнего провайдера входа обновляются при каждом входе
Список значений	Явно перечисленные значения, по одному в строке
Выражение	Произвольное условие, см. Правило-выражение

Блок Кому адресовано выглядит по-разному. У правила по атрибуту это переключатель Всем: выключите его, чтобы выбрать конкретных пользователей и группы. У правила со списком значений — сразу два списка с флажками, Пользователи и Группы, с кнопками «Выбрать все» и «Сбросить».

Переключатель «Правило включено» выключен по умолчанию

Заполнив форму и нажав Готово, вы получите сохранённое, но неработающее правило. Включайте переключатель до сохранения — либо потом прямо в списке правил.

Правило-выражение

Вид Выражение нужен, когда условие сложнее списка значений: несколько полей, «или», разные правила для разных пользователей в одной формуле. Внутри доступны функции, которые платформа подставляет в момент запроса:

Функция	Во что превращается
USER_NAME()	Логин текущего пользователя
USER_ID()	Его идентификатор
IN_GROUP('код')	Истина, если пользователь состоит в группе с этим кодом. Код группы виден в её карточке — Пользователи и группы
IN USER_ATTR('имя')	Список значений атрибута пользователя

Например, правило, адресованное всем,

[customers.city] = 'Москва' OR USER_NAME() = 'ivanov'

оставляет всем только московские продажи, а пользователю ivanov — данные целиком.

USER_ATTR пишется только после IN

Атрибут может иметь несколько значений, поэтому сравнивать его на равенство нельзя. Запись [поле] = USER_ATTR('region') платформа отклонит с пояснением, что функция допустима только в позиции IN. Правильно: [поле] IN USER_ATTR('region').

Как убедиться, что правило не погасило данные всем

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

Сохранённые правила перечислены списком: переключатель включения, название, вид, объект и поле, кому адресовано, а справа — корзина для удаления.

Правила сохраняются сразу

У окна видимости строк нет отдельной кнопки «Применить»: правило сохраняется в момент создания, а действовать начинает, как только включён переключатель Правило включено.

Что дальше

• Проверка правил видимости — как убедиться, что правило работает так, как задумано.
• Каждому свои данные — готовый порядок для внешних получателей.
• Видимость полей (CLS) — ограничение по колонкам, работает отдельно.
• Журнал обращений — итоговый SQL с подставленным правилом.