Цитата:
Сообщение от
Владимир Максимов
Если я правильно понял, то основное правило работы с Security Keys заключается в следующем
- На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
- Права даются на объекты, подключенные к соответствующему Security Keys
Все остальное - это уже следствие данного правила, тонкости реализации и ошибки функционала.
Другими словами Security Key выполняется функцию не собственно назначения прав, а всего-лишь предоставляет возможность настроить права подчиненных объектов. Делает не вполне то, для чего был задуман. Перестал быть "работягой" и стал "начальником"
До Ax2009 все было так, в принципе.
- Если не считать кое где явную проверку прав на ключ в коде некоторого функционала (hasSecuritykeyAccess), в том числе самописного.
- Если не считать, что некоторые "Умельцы" которые делали Российский функционал в Ax3.0 "вешали" ключ прямо на меню (а не на MenuItem, это касалось например, модуля "зарплата")
В этих случаях приходится давать права на ключ а не на объект.
В Ax2009 применили странную систему. С одной стороны старая система проверки прав на объекты осталась. С другой стороны ряд функционала, (о которой описано выше) требует права на ключи а не на объекты. Например система "AOSAuthorization" работает только с правами на ключи, а не на объекты, и не всегда это легко "обойти".
Например в форме настройки стандартного фильтра Ax2009 при попытке "присоединить" источник данных другой таблицы (n:1 или 1:n) пользователь "увидит" только те таблицы, на
КЛЮЧ которых у него есть права, а не на
ОБЪЕКТ таблицы, на которую имеет доступ.
И еще одна особенность AX2009 по сравнению, например с Ax3.0.
Если ранее loockup поля "открывались" даже на те таблицы, на которые у пользователя прав нет, то в Ax2009 lookup так же проверяет права доступа. Если доступа на таблицу нет - открывается "пустой" lookup.