Gustav: Unsorted, или Записки DAX-дилетанта - II

[Gustav]

Цитата:

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

Наверное, лучше посты сделать отдельными темами, а не все в одну кучу....

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

[belugin]

Цитата:

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

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

Дело не в наполнении скорее, а в комментировании.

[Gustav]

Недавно я сам давал совет про ограничение доступа на уровне записей, где излагал некоторую ситуацию, реализованную в нашей инсталляции Аксапты (3.0 SP4, приложение GMCS):

Цитата:

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

Администрирование \ Настройки \ Контроль доступа \ Доступ на уровне записей \ Ctrl+N

И далее Мастером настраиваете фильтр на таблицу "Картотека номенклатуры" для определенной группы пользователей. У вас их получается две, значит создадите две записи в этой табличке "Доступ на уровне записей".

У меня сделано следующим образом. Есть общая группа, назовем ее "ВсеНоменклатурщики", в которую входят все подобные пользователи. Этой группе прописаны общие права для всех пользователей, но на таблицу "Картотека номенклатуры" выставлен полный запрет.

С другой стороны есть группы "Номенклатурщики1" и "Номенклатурщики2", у которых полный запрет прописан на всё, кроме таблицы "Картотека номенклатуры". На эту таблицу прописан полный доступ.

Каждый пользователь входит в одну из этих групп и в общую.

Для групп 1 и 2 создаются записи в таблице "Доступ на уровне записей" как описано выше. Помимо этого в этой таблице у меня создана запись и для группы "ВсеНоменклатурщики", у которой в фильтре по полю код номенклатуры указано слово "никакая" (т.е. некоторое несуществующее значение).

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

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

Дальше - больше! Похоже, что я совсем не одинок в своих заблуждениях. Не знаю, настраивали ли когда-нибудь самостоятельно RLS авторы оригинала книги Microsoft Dynamics AX 4.0 (или не барское это дело ), но читаем следующее:

Цитата:

(в английской версии):

Important. If an application role that uses multiple user groups has record-level security applied on a certain table within a company account, maximum access is given to the role. For example, if one user group has no record-level security for the Customer table and another user group allows users to see only a subset of the customers, the user will have access to all customers.

(и перевод - в русском издании, на странице 363):

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

Увы, но это не так, или, как станет ясно ниже, наоборот - ура, что это не так!

В общем, прозрение таково: доступ и RLS - являются понятиями как бы независимо параллельными. Вначале системой для пользователя выбирается максимальный доступ из всех групп (пока без учета RLS). И далее, если хотя бы у одной группы есть RLS, то эта RLS применяется. Если одна группа - "Просмотр" + RLS, а другая "Полный доступ" без RLS, то у пользователя будет "Полный доступ" + RLS. В случае нескольких групп с разными настройками RLS отдельные фильтры RLS от разных групп для одного пользователя объединяются в SQL-предложении WHERE при помощи операции ИЛИ (OR).

Дошёл я до этого, спустя несколько недель после моего совета, когда мне пришлось решать иную, я бы сказал, обратную задачу: нужно было не "дать некоторым, запретив остальным", а "ограничить некоторых, не трогая остальных". Речь шла о справочнике "Код складского журнала" (таблица InventJournalName), который у нас содержит 7 записей, определяющих типы складских журналов. Некая складская роль "Кладовщик" у нас состоит из нескольких групп, настройки каждой из которых достаточно многообразны. Новой группе людей нужно было дать возможность создавать журналы только двух типов из семи, при всём при том, что все остальные настройки, определяемые по совокупности нескольких групп, для роли "Кладовщик" должны были остаться такими, как были. С кислым выражением лица накануне 8 марта я думал о том, как мне придется закрывать у всех уже ранее настроенных групп роли доступ к таблице InventJournalName, после чего создавать и заполнять две новые группы - "Все 7" и "Только 2", с содроганием думая о возможной перспективе возникновения необходимости ограничения доступа к еще какой-нибудь таблице, когда опять придётся изменять настройку уже существующих групп...

К счастью, всё прояснилось до практических телодвижений и ничего из ранее сформированных групп трогать не пришлось. Была создана группа "Только 2" с указанными RLS-ограничениями на таблицу InventJournalName, которая была назначена новым людям в дополнение к остальным (стандартным) группам роли "Кладовщик".

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

Цитата:

http://erpkb.com/Axapta/DostupNaUrovneZapisejj - belugin
:
Чтобы настроенный RLS заработал, надо, чтобы у группы был хоть какой-то доступ к таблице.

Да, хотя бы "Просмотр", лишь бы не "Нет доступа"! В данном случае вариант "Нет доступа" не следует считать наиминимальнейшим уровнем доступа, а следует считать полным, не принимаемым ни в какое внимание, осутствием доступа.

Цитата:

http://axapta.mazzy.ru/lib/rls_setup/ - mazzy
:
RLS в Аксапте работает совместно с системой настройки обычных прав. Это значит, что для того, чтобы ограничить доступ к тому или иному полю таблицы, необходимо настроить обычные права на эти таблицу. Задача RLS - незаметно для пользователя отфильтровать записи.
...
Настройка ограничения прав на уровне записей сводится к определению фильтров на те или иные таблицы для разных групп пользователей. Если пользователь входит в несколько групп, то фильтры объединяются по условию ИЛИ.
...
Axapta смотрит на обычные права доступа. И, если право доступа есть, то смотрит в настройки RLS. Если для данной группы и данной таблицы настроек RLS нет, то Аксапта показывает все записи из таблицы.

Цитата:

http://forum.mazzy.ru/index.php?s=&s...ndpost&p=15230 - glibs
:
Не знаю, новость ли это для остальных, но приятная. Если у пользователя нет доступа к определенному значению из таблицы на уовне RLS, то validate relation-а на таблице в lookup срабатывает корректно. Т.е. если есть две группы клиентов Х и У, я могу видеть только группу Х, то создать запись в таблице клиентов и вручную ввести группу У система не позволяет. Раньше с этим были проблемы.

Для меня - очень приятная! Я был в шорах предубежденности, что даже если значение не показывается в выпадающем списке, то его можно прописать вручную или вставить копированием - возможно, я как раз и начитался информации про версию 2.5?

[Gustav]

ПРОБЛЕМА:

Необходимо для заданной группы прав настроить RLS на таблицу "Коды журналов ОС", которой нет в списке таблиц, отображаемых в Мастере. Таблица "Коды журналов ОС" в нашем сильноэксклюзивном приложении от компании GMCS называется GM_RAssetJournalName.

РЕЦЕПТ:

1. Открываем форму "Доступ на уровне записей" (SysRecordLevelSecurity), до которой предварительно добираемся по меню Ax 3.0: Администрирование \Настройки \Контроль доступа \Доступ на уровне записей.

2. Находясь в гриде, жмем Ctrl+N и создаем при помощи Мастера запись для заданной группы и какой-нибудь произвольной таблицы, которая нам не нужна, но которая видна в списке Мастера, например, "Модели учета" - RAssetStandardTable (она видна в раскрытом узле "СНГ Основные средства" после включения опции "Показать все таблицы").

3. Закончив шаги Мастера, выходим из формы "Доступ на уровне записей", не настраивая для созданной записи никаких фильтров (т.е. не пользуемся кнопкой "Запрос").

4. В таблице SysRecordLevelSecurity в нужной записи меняем код "ненужной" таблицы на код требуемой таблицы любым удобным способом - вручную (через Обозреватель таблицы или средствами СУБД) или при помощи элементарного джоба:

static void Job_UpdateRLSrecord(Args _args)
{
    SysRecordLevelSecurity sysRLS;
    ;
    ttsbegin;

    select forupdate sysRLS
        where sysRLS.companyId == curExt()
           && sysRLS.groupId == '<наша группа прав>'
           && sysRLS.tabId == tablenum(RAssetStandardTable);

    sysRLS.tabId = tablenum(GM_RAssetJournalName);
    sysRLS.update();

    ttscommit;
}

5. Снова открываем форму "Доступ на уровне записей", находим нужную запись - видим в колонке "Название таблицы", что таблица благополучно поменялась.

6. Нажимаем кнопку "Запрос" и выполняем требуемую настройку фильтра для нашей таблицы.

7. "Захардкодиваем" код нашей таблицы в метод buildTableTree формы SysRecordLevelSecurityWizard. Это необходимо для того, чтобы возможные последующие настройки RLS для данной группы прав не снесли нашу, с таким трудом вживленную, таблицу. Для этого меняем условие в IF - тупо, зато быстро, расширяя его на ИЛИ с нашей таблицей:
c

if (dictTable &&
    dictTable.allowSecuritySetup() &&
    (dictTable.tableGroup() == TableGroup::Main ||
     tableSelection.selection() ||
     tableIds.in(tableId)) &&
     (domainAccess || SysRecordLevelSecurityWizard::tableAllowed(tableId)))

на

if (
   (dictTable &&
    dictTable.allowSecuritySetup() &&
    (dictTable.tableGroup() == TableGroup::Main ||
     tableSelection.selection() ||
     tableIds.in(tableId)) &&
     (domainAccess || SysRecordLevelSecurityWizard::tableAllowed(tableId)))
   ||
   tableId == tablenum(GM_RAssetJournalName)
   )

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

ИСТОЧНИКИ (ВДОХНОВЕНИЯ):

Еще по поводу QueryBuildRange()
Коды аналитики

[Gustav]

В Excel есть замечательная функция рабочего листа TRIM (в русской версии - СЖПРОБЕЛЫ). Она не только удаляет ведущие и концевые пробелы, как это делают функции strLTrim и strRTrim в X++ (или LTrim и RTrim в VBA, Oracle и т.д.), но и оставляет между словами только по одному пробелу, например:

TRIM(" Доход   за   первый    квартал   ") равняется "Доход за первый квартал".

Сегодня я понял, что чувствую себя в Аксапте очень неуютно без подобной функции. И, поскольку ничего подходящиего ни среди системных функций, ни среди методов класса Global я не нашёл, то слепил свою собственную:

static str trimLikeExcel(str _sourceString)
{
    // имитация табличной функции TRIM из Excel
    // удаляем пробелы до тех пор, пока между словами не останется только по одному пробелу
    str strTmp;
    int lenPrev, lenCurr;
    ;

    strTmp = strLRTrim(_sourceString);
    lenCurr = strLen(strTmp);
    do
    {
        lenPrev = lenCurr;
        strTmp = strReplace(strTmp, '  ', ' '); // многократная замена 2-х пробелов на 1
        lenCurr = strLen(strTmp);
    }
    while (lenCurr != lenPrev);

    return strTmp;
}

Функцию можно поместить в класс Global или в какой-нибудь собственный класс-набор статических методов (а-ля "персональный Global").

Кстати, имеющаяся в VBA и Oracle функция Trim действует не более, чем как метод класса Global strLRTrim (т.е. просто выполняет оба действия - "левое" и "правое" - одновременно). Пробелы же между словами, которых может быть более одного, она не трогает.

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