Есть подозрение что нельзя
По крайней мере для прав на таблички нельзя.
Вот документация
Role based security use patterns for developers_AX2012.pdf
https://www.microsoft.com/en-us/down....aspx?id=39068
Со стр.22
(мое мнение – сперва в ядре наколбасили, а затем переделывать не стали и дописали фикс в X++
Колхоз конечно но хотя бы так сделали.)
Цитата:
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