Права на таблицу. Акс2012

[Perc]

Делаю новую простую форму для теста (ну и менюитем к ней). На ней два датасорса InventDim и PurchLine - не связаны между собой ну и два грида соответственно.
Делаю отдельную привилегию и включаю в нее только один мюнюитем с правами Read. Добавляю привилегию в стандартную роль WMSWarehouseManager.
Захожу в акс под пользователем который имеет только эту роль, и запускаю тестовую форму.
Датасорс InvenDim доступен для редактирования, а PurchLine нет. Не могу найти причину такого поведения. Смотрю форму "Просмотр связанных ролей безопасности" для этих таблиц - и они никак не касаются роли - WMSWarehouseManager.
В чем секрет?

[Logger]

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

[Perc]

Что там могло автоматически приджойниться?
Как это работает не понимаю..

[Владимир Максимов]

Исходя из описания, обе таблицы должны быть только на чтение. Т.е. с PurchLine как раз все правильно. Это с InventDim какая-то проблема.

С другой стороны, обычно InventDim напрямую на форму не выводят, а делают "прослойку" из некоего "буфера" с тем, чтобы по введенным пользователем значениям складских аналитик найти запись InventDim. Возможно, Вы эту идеологию и реализовали. Т.е. на форме у Вас не собственно InventDim, а ее копия для редактирования. И вот на эту копию не распространяются настроенные права доступа

Ну, еще, на всякий случай, посмотрите, нет ли у роли WMSWarehouseManager чего-нибудь в узлах "Permission" и "Sub Role"

[Logger]

Цитата:

Сообщение от Владимир Максимов

Это с InventDim какая-то проблема.
...
Ну, еще, на всякий случай, посмотрите, нет ли у роли WMSWarehouseManager чего-нибудь в узлах "Permission" и "Sub Role"

Возможно это чего-нибудь сидит в роли SystemUser

[Perc]

Цитата:

Сообщение от Владимир Максимов

..С другой стороны, обычно InventDim напрямую на форму не выводят, а делают "прослойку" из некоего "буфера" с тем, чтобы по введенным пользователем значениям складских аналитик найти запись InventDim. Возможно, Вы эту идеологию и реализовали. Т.е. на форме у Вас не собственно InventDim, а ее копия для редактирования. И вот на эту копию не распространяются настроенные права доступа

Да, про методику работы c InventDim на формах я помню. Там в классах InventDimCtrl_Frm свои ограничения еще реализованы. Но даже в этом случае датасорс InventDim на форме есть и системные права на него распространяются.
Но в моем случае форма тестовая и делалась без "всего этого". Два DS, два грида и никакого кода.

Цитата:

Ну, еще, на всякий случай, посмотрите, нет ли у роли WMSWarehouseManager чего-нибудь в узлах "Permission" и "Sub Role"

Подчинённых ролей там тоже нет. Я проверял специально на "пустом" приложении.

[Perc]

Права в акс2012, тема для меня оказалась с сюрпризами. Ранее не доводилось особо вникать.

1. Форма "Просмотр связанных ролей безопасности". Показывает откровенную чепуху. Вернее много чего не показывает. Там даже по коду нашел место где косяк. У меня на пустом приложении (sys слой только), для InventDim показывает пустую форму.

2. Права на таблицу в форме могут протягиваться со всех форм с этой таблицей в DS. Ну не со всех форм, а до кого есть доступ у роли.
Т.е. есть две формы с датасорсом Table1, с деревом Permissions выданным по дефолту. На каждую форму делаем менюитем, которые включаем в привилегию - один менюитем с доступом Read, другой Delete. Ну и привилегию в тестируемую роль добавляем. И при запуске выясняем, что в обоих формах права на DS Table1 - Delete.

Если на второй форме в Permissions\delete, для таблицы Table1 уменьшаем доступ, то при запуске первой формы доступ до Table1 тоже уменьшается.


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

И условная задача, запретить правку склада в скл аналитике заказа, администрированием вообще не решается.

[Logger]

Цитата:

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

Если на второй форме в Permissions\delete, для таблицы Table1 уменьшаем доступ, то при запуске первой формы доступ до Table1 тоже уменьшается.
...
В общем администрирование ужас...

Ужас.
Но не ужос-ужос-ужос.

Ваша ситуация описана в документе
Role based security use patterns for developers_AX2012.pdf

Цитата:

8. Over-permissioning
Earlier portions of this white paper concerned issues around under-permissioning. We made recommendations about which permissions level should be granted when you develop with various programming objects. Some of these recommendations were explained by listing the problems that weaker permission levels might cause.
Now we take the opposite perspective and look at over-permissioning. The following sections explain various scenarios and patterns where too much access has been granted to roles that do not need the access and should not have it.
Pattern: One menu item reused many times
A given action menu item is invoked from many different places in the application. If some of those places need stronger security permission than others, the application is over-permissioned.
A simple solution is to create a separate action menu items for each security context. Expose each menu item to the security model as different entry points.
Pattern: One form with many contexts
A given form may be invoked by many menu items. Each menu item provides a different context to the form.
An example is accounting distributions, where one accounting distribution form is used for many document contexts.
A user can have both Read and Delete permissions to a given table:
• In the role-based security model, the role can have Read permission on a given table from one privilege, plus Delete permission on the same table from another privilege.
• Alternatively, a given user might be in multiple roles, where one role has the Read privilege and the other role has the Delete privilege.

During run time, the security system calculates a user’s final access level by a union of all the user’s permissions. Therefore, even when the user clicks a menu item that is intended for Read only, the user has Delete access to the table while using the form.
How does the developer prevent a given form from offering full access when the form was called by a menu item that is intended to merely read the data? You can force the Microsoft Dynamics AX system to use the security permissions that are granted with the calling menu item. Place the following line of code in the form’s init method, after the call to super:
FormSecurity::setFormDataSourceMaxAccessRight(this);
Pattern: Many forms sharing the same table
This is somewhat similar to the preceding pattern.
An example is financial journal lines. The data for the financial journal lines is kept in one table, but each of the journals has a different journal line form.
The solution is, again, to force the Microsoft Dynamics AX system to use the security permissions that are granted by the calling menu item. Place the following line of code in the form’s init method, after the call to super:
FormSecurity::setFormDataSourceMaxAccessRight(this);

Pattern: Form data source access elevation
The developer should ensure that the form’s data sources have their Allow* properties set to allow only the minimum access that is necessary for the form to function. For example, if the form never needs to delete data from a given data source, the AllowDelete property on that data source should be set to No.
The forms auto-inference provider uses these property values to determine the level of access for the form permission. Permissions that are unnecessarily elevated can expose more functionality than necessary in other forms. This is because the security model unions table access level together and uses the highest level everywhere.
Pattern: One form with many contexts, each of which exposes common polymorphic behavior
One form can be opened from a variety of different contexts and can provide similar behavior across all those contexts.
Example
The LedgerJournalTable form exposes a single post menu item button. Depending upon the context, the form must define the appropriate posting menu item functionality.
Solution
Create different menu items for the various common behaviors. Based on the calling context, dynamically set the menu item name:
post.menuItemName(menuitemActionStr(LedgerJourPostLJTransDaily));
Pattern: Nested contexts
A form that can be opened from a variety of different contexts invokes another form that can also be opened from a variety of contexts.
Example
Miscellaneous charges can contain multiple contexts that invoke accounting distributions, which can also contain multiple contexts:
PurchTable form > MarkupTrans form > AccountingDistribution form
Reference
MarkupTrans.enableAccountingDistributionButton
Solution
1. Create separate menu items for each of the source and destination contexts.
2. Based on the input context, set the menu item button name for the destination context:

buttonDistributeAmount.menuItemName(menuitemDisplayStr(AccountingDistMarkupTransPO));


3. Define the security model so that the entry point access levels between the source and destination menu items are aligned.
4. Reduce the form data source access by only the table access right for a specific menu item:

FormSecurity::setFormDataSourceMaxAccessRight(this);
Pattern: Securable controls
A form that can be opened from a variety of different contexts has securable controls. The security system unions together all the access levels of the securable controls from all contexts. By default, the user is granted the maximum access by the union.
Problem
Relying on the NeededPermission property of the controls can result in over-permissioning.
Solution
Use the following method to enable the controls according to feature requirements:
FormSecurity::getMenuItemAccessRight

Похоже недостает вызова

FormSecurity::setFormDataSourceMaxAccessRight(this);

на init методе формы

Мы его вообще поставили в
\Classes\SysSetupFormRun\init

    // В формах доступ на Создать/Удалить должен регулироваться доступом к пункту меню  -->
    if (!isSystemAdministrator() && this.args() && this.args().menuItemName())
    {
        FormSecurity::setFormDataSourceMaxAccessRight(this);
    }
    // В формах доступ на Создать/Удалить должен регулироваться доступом к пункту меню  <--

Вроде живет норм, есть не просит.

P.S.
см. также
Настройка доступа к менюайтему DAX2012

[Perc]

Цитата:

см. также
Настройка доступа к менюайтему DAX2012

Вот, вы обо всем давно в курсе. Но в первом комментарии в этой теме даете совершенно надуманные версии)

Цитата:

FormSecurity::setFormDataSourceMaxAccessRight(this);

Да много раз встречал это в коде, но не очень понимал зачем это. Это выглядело как программное делание того, что и так должно было быть сделано стандартом. А оказывается вон оно че.. Но хотелось не только DS регулировать, но и поля в DS раздельно. Понятно в общем..