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

[DesparioN]

Добрый день!

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

Пытался настроить через needpermission, но доступ либо полностью отсутствует, либо всегда есть.

Это как то можно реализовать с помощью настроек или только через код?

[Pandasama]

Цитата:

менюайтем функции, доступ к которому нужно параметризировать в зависимости от способа открытия формы

Обычно это просто делают через метод .enabled() у контрола кнопки

[sukhanchik]

Цитата:

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

Это как то можно реализовать с помощью настроек или только через код?

Для ответа мало входящих данных.

Цитата:

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

Обычно это просто делают через метод .enabled() у контрола кнопки

В общем случае - только так.

Но ответ на конкретный вопрос зависит от того, что из себя представляет "способ открытия формы", от которого зависит доступность пункта меню.
1. Если один и тот же пользователь должен иметь доступ к пункту меню или не иметь в зависимости от "способа открытия формы" - то да, такой случай только программируется. Пример: Открытие справочника клиентов из меню или же из меню "Просмотр подробных сведений"
2. Если "способ открытия формы" четко разделен по пользователям и каждый конкретный пользователь имеет только "свой способ", в котором пункт меню либо доступен, либо недоступен - то доступность пункта меню можно настроить через привилегии без программирования. Пример: журнал ОС и общий журнал ГК. Технически - это разные пункты меню, но одна и та же форма. При этом кнопка "Строки" очевидно ссылается на разные пункты меню.

[DesparioN]

Наверное не корректно написал.
Чтобы было проще. У формы PriceDiscTableList есть 2 menuitem: PriceDiscTableList_Cust и PriceDiscTableList_Vend. Они добавлены в разные роли с разным уровнем доступа (Read и Correct)
На форме есть menuitem PriceDiscClose. Мне нужно дать доступ к функцию только если форма открыта c уровнем доступа Correct.

Я реализовал через securityRights.menuItemAccessRight(SecurableType::MenuItemDisplay, element.args().menuItemName()) >= AccessRight::Correction, но подумал можно ли сделать красивее настройками.

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

Цитата:

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

Наверное не корректно написал.
Чтобы было проще. У формы PriceDiscTableList есть 2 menuitem: PriceDiscTableList_Cust и PriceDiscTableList_Vend. Они добавлены в разные роли с разным уровнем доступа (Read и Correct)
На форме есть menuitem PriceDiscClose. Мне нужно дать доступ к функцию только если форма открыта c уровнем доступа Correct.

А что не получается-то? У Вас же не вопрос разных уровней доступа, а просто отображать пункт меню на форме или нет.

1. Для пункта меню PriceDiscClose создаешь привилегию с уровнем доступа Correct
2. Включаешь эту привилегию в ту роль, которая открывает форму с уровнем доступа Correct. Я так понимаю, это роль PriceDiscTableList_Vend

Собственно, все. Если форма открыта через роль с уровнем доступа Read, то пункт меню вообще не будет отображаться на форме. Поскольку контролирующая этот пункт меню привилегия в роль на чтение не включена.

Могут быть накладки, если пункт меню включен в несколько привилегий или одна привилегия включена в несколько ролей. Но, насколько я понимаю, здесь такая задача не ставиться

PS: Я исхожу из предположения, что для пользователя назначена только какая-то одна роль. Или на чтение или на изменение. Если для одного и того же пользователя назначены обе роли, то без программирования не получится

[DesparioN]

Цитата:

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

PS: Я исхожу из предположения, что для пользователя назначена только какая-то одна роль. Или на чтение или на изменение. Если для одного и того же пользователя назначены обе роли, то без программирования не получится

Как раз второй вариант

[Logger]

Цитата:

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

Обычно это просто делают через метод .enabled() у контрола кнопки

У датасорсов есть отдельный метод для "понижения" уровня доступа
maxAccessRight
см
\Classes\FormSecurity\setFormDataSourceMaxAccessRight

Может для контролов / менюитемов что-то найдется.

[Logger]

Есть подозрение что нельзя
По крайней мере для прав на таблички нельзя.

Вот документация
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