Показать сообщение отдельно
Старый 11.03.2008, 19:38   #10  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Преодоление принципиальных RLS-заблуждений
Недавно я сам давал совет про ограничение доступа на уровне записей, где излагал некоторую ситуацию, реализованную в нашей инсталляции Аксапты (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?
За это сообщение автора поблагодарили: GLU (1), Logger (3), gl00mie (5).