Суммарный RLS запрос в виде SQL

[AGRESSOR]

Уважаемые пользователи форума.
Ситуация:
Пользователь User1 состоит в группах Group1, Group2, Group3
Для каждой из этих групп настроен RLS на таблицу Table1.
Вопрос:
Как посмотреть суммарный запрос, который уходит на сервер при запросе пользователем User1 данных из таблицы Table1.
Причем нужно сделать это в коде, т.к. нужна информация по всем пользователям-таблицам...
Ax 4.0 sp02

[Alexius]

Если СУБД MS SQL, то на мой взгляд, удобнее всего воспользоваться профайлером (SQL Server Profiler)

[AGRESSOR]

Профайлером в этом случае думаю удобно воспользоваться в случае с 2-3мя пользователем и 2-3мя таблицами.
А если пользователей 1000? и неизвестно сколько у них пересекающихся в каждой таблице RLS -ов...
Хотя может я чего-то о профайлере не знаю =)

[Alexius]

Тогда поподробнее о задаче:
- Нужно смотреть в рабочей или тестовой базе ?
- Требуется отследить запросы для определенного числа форм/отчетов и т.п. или провести глобальный мониторинг ?
- Прочие особенности

[AGRESSOR]

1) на рабочей
2) глобальный мониторинг
3) база MS SQL... не знаю что еще дополнить =)

[Alexius]

Тогда действительно профайлер не пойдет.

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

[AGRESSOR]

Ну дак это небольшая проблема: получить пересекающиеся в таблице RLS запросы для каждого пользователя... Вопрос в том, что делать с ними дальше, ведь нужно получить SQL-запрос, пришедший на сервер БД из ядра Аксапты...

[Alexius]

Безумная идея:

В Class/SysQueryRun/new для нужных таблиц добавить range типа

strfmt('((DataAreaId == DataAreaId) || (DataAreaId == "%1"))', curuserid())

это если длина кода пользователя <=3

strfmt('((DataAreaId == DataAreaId) || (TableField == "%1"))', curuserid())

TableField - любое строковое поле таблицы с длиной >=5

strfmt('((DataAreaId == DataAreaId) || (RecId == %1))', xUserInfo::find().RecId)

RecId пользователя будет потом несколько сложнее разобрать, но возможно.

В профайлере добавить фильтр на текст %DATAAREAID=DATAAREAID% (сомневаюсь, что найдутся еще такие запросы ).

PS. По SysQueryRun например тут Не работает RLS по связанной таблице. Так и должно быть?

PS2. Реализация и последствия на Вашей совести

[Wamr]

глупый вопрос.
а какова цель данного исследования?

[AGRESSOR]

2 Wamr: Цель - предоставить начальству отчет вида Пользователь-Таблица-Суммарный запрос"

[Alexius]

Цитата:

Сообщение от AGRESSOR

2 Wamr: Цель - предоставить начальству отчет вида Пользователь-Таблица-Суммарный запрос"

Постановка задачи уже лучше

1. Если босса удовлетворит разграничение в терминах АХ, то можно просто построить запросик по таблицам:
- UserInfo
- UserGroupList
- SysRecordLevelSecurity
- может еще что-то

2. Если нужно именно в виде предиката MS SQL, то
а. Развертываем копию рабочей базы
б. В Class/Info/startupPost добавляем формирование и запуск Query для нужной таблицы с range описанным выше. (не забываем исключить из "праздника" себя любимого )
в. Делаем job/class для запуска в цикле Аксапты под всеми (выбранными) пользователями.
(можно использовать за основу Тестирование прав пользователей. DAX 4.0.)
г. Настраиваем профайлер на базу и запускаем его.
д. Запускаем пункт в
е. Выбираем из профайлера получившиеся запросы и парсим их.

PS.Вариант 1 мне нравиться гораздо больше

[oip]

Цитата:

Сообщение от AGRESSOR

2 Wamr: Цель - предоставить начальству отчет вида Пользователь-Таблица-Суммарный запрос"

Просто предоставить отчет - это не совсем цель. Сам по себе отчет без процедуры обработки данных из него бесполезен. Отчет - это возможный способ достижения цели. Цель - это, например, провести анализ запросов на предмет возможной оптимизации групп. Или проверить, как именно RLS работает в случае нескольких групп. Или еще что-то. Начальство-то что от этого отчета хочет? Может мы придумаем более правильный способ?

Цитата:

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

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

[Vadik]

Цитата:

Сообщение от AGRESSOR

2 Wamr: Цель - предоставить начальству отчет вида Пользователь-Таблица-Суммарный запрос"

Если у Вас есть ВНЯТНО спроектированная структура групп пользователей, если RLS группы отделены от групп с правами пользователей, достаточно простого как дверь отчета { Пользователь - Имя - Группа - Описание }. Если нет - наведите таки порядок или продолжайте рожать ежиков

[_scorp_]

Цитата:

Сообщение от Vadik

если RLS группы отделены от групп с правами пользователей

К сожалению не во всех версиях AX так можно делать.

[Vadik]

Цитата:

Сообщение от _scorp_

К сожалению не во всех версиях AX так можно делать

А можно с этого места поподробнее? Например, в каких версиях это нельзя сделать?

[_scorp_]

Цитата:

Сообщение от Vadik

А можно с этого места поподробнее? Например, в каких версиях это нельзя сделать?

Вот. В AX 3.0 RLS-права работают по аддитивному принципу. В AX 4.0 изменили на рестриктивный. В AX 2009 вернули аддитивный. Мне больше нравится реализация в AX 4.0.
Приведу пример почему мне больше нравится настройка RLS-прав в AX 4.0. Пример задачи:
1. Менеджеры должны работать с определенными типами объектов.
2. Каждый менеджер может смотреть продажи по определенным регионам.

Реализация в AX 4.0:
1. Создаю группу пользователей "Менеджер". Для этой группы настраиваю права доступа. (Права на объекты, не RLS.)
2. Создаю столько столько групп пользователей сколько регионов. Для каждой группы устанавливаю RLS-права на свой регион.
3. Настройка прав менеджера сводится к включению его в группу "Менеджер" и если, например, он может видеть продажи трех регионов, то включение его еще в три группы соответствующих регионов.

Реализация в AX 2009
1. Для каждого менеджера создаем отдельную группу.
2. На эту группу настраиваем права.
3. На эту группу настраиваем RLS-права.
4. Включаем менеджера в настроенную группу.

Вся соль заключается в поддержке решения.
1. Разрешить менеджерам работать с отчетом "А". В AX 4.0 нужно для группы
"Менеджер" дать права на отчет "А". В AX 2009 нужно для группы каждого менеджера добавлять права на отчет "А".
2. Дать конкретному менеджеру права на просмотр продаж по дополнительному региону. В AX 4.0 нужно просто "киинуть" этому пользователю RLS-группу соответствующего региона. В AX 3.0 и 2009 нужно для группы этого менеджера править настройку запроса RLS.

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

[ViV]

_scorp_, немного не поняла, в чем проблема сделать в 3-ке также как вы привели для 4-ки пример?
у нас в 3-й (SP3) сейчас настроено так - есть общая группа "кассир" - где выданы все права на работу с кассами (не RLS).
и отдельно группы Касса1 Касса2 Касса3 и т.д. - где права на конкретную кассу (ограничены RLS)
все работает отлично.

[Ivanhoe]

Поведение тройки, например: Проблема с RLS и SecurityKey.
Про различия 3.0 - 4.0 - 2009 обсуждалось, например, начиная с этого поста: Безопасность на уровне записей

[AGRESSOR]

2 Alexius:
Большое спасибо. За основу взял ваш второй вариант, так как нужен именно SQL-запрос
2 oip, Vadik:
Смею предположить, что именно оптимизацией групп и хочет заняться начальство
Оффтоп:
Сам ненавижу работать без понимания цели, но начальство оно ж Там, а мы тут