Проверка меню на наличие пунктов без ключей контроля доступа (SecurityKey)

[gl00mie]

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

• по умолчанию проверяется главное меню;
• при желании класс легко прикрутить в контекстное меню для проверки любого меню из AOT;
• если ветка меню или отдельный пункт закрыты отключенным конфигурационным ключом, то они не проверяются;
• если пункт меню без ключа контроля доступа встречается в меню несколько раз, то информация о нем выводится лишь единожды;
• в выводимой информации указывается, кто и когда создал или последним изменил пункт меню.

Код проверялся на AX 2009, но на 4-ке тоже должен работать. Единственная особенность: класс может не скомпилироваться, если у вас нет Global::callStack2Infolog() - из стандартного приложения его выкинули в рамках вычищения "мертвого" кода, но я лично его активно использую, так что либо потрите соотв. строки кода в классе, либо верните метод обратно

[BOAL]

Спасибо. А то сталкивался на Ах4 сп2, когда для меню пакетного юзера, где только пер. опер\пакетник должна быть висели менюшки, криво сидящие или не висящие вообще (польско-венгерские функции). Там еше и в дереве самих Сек. Кей кто-то в корень напакостил ключиками без подчинения, то же с _PL
И куда смотрит ОТК?
А для своей разработки первое дело такой утилитой все проверить - забываются эти моменты часто.

[Timofey_k]

Цитата:

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

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

А Best Practices проверить на ноде Menu Items не катит?

[gl00mie]

Цитата:

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

А Best Practices проверить на ноде Menu Items не катит?

Нет, не катит - это совершенно разные множества. Отнюдь не все пункты меню обязаны иметь ключи контроля доступа (хоть это и желательно), но те пункты, которые находятся в главном меню и доступны с учетом перечня включенных конфигурационных ключей, обязаны быть закрыты ключами контроля доступа по любому. Тут, как это часто бывает, вся суть в детялах:

• как отдельные ключи, так и целые ветки меню могут быть отключены конфигурационными ключами - и тогда мне (и, главное, людям, раздающим права доступа) совершенно не интересно, есть там ключи контроля доступа или нет. Скажем, в стандартном функционале, касающемся Польши, кажется, есть пункты главного меню, не закрытые ключами контроля доступа, но поскольку в моем случае польский функционал выключен конфигурационным ключом, видеть такие пункты меню при каждой проверке совершенно излишне;
• пункты меню сами по себе могут не иметь привязанных ключей контроля доступа, но таковые могут быть привязаны к некоему подменю, в котором находятся эти пункты, и тогда получается, что и пукты меню закрыты ключами контроля доступа, пусть и опосредованно;
• могут быть созданы пункты меню, не закрытые ключами контроля доступа, но пользователь, тем не менее, никогда до них не доберется (к примеру, может быть пункт меню, нужный лишь для запуска job'а на сервере, а не на клиенте), стало быть, людей, раздающих права доступа, и меня такие пункты тоже не должны интересовать.

В общем, инструмент был создан главным образом для того, чтобы при очередном обновлении рабочего приложения не подложить свинью тем, кто раздает права пользователям, а не для того, чтобы подменить уже имеющиеся и исправно работающие проверки Best Practices.

[glibs]

Цитата:

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

...
Отнюдь не все пункты меню обязаны иметь ключи контроля доступа
...

Почему?

ВР требует наличия security key на menu item. Я тоже придерживаюсь такого мнения. Права доступа раздавать приходится постоянно. Когда SC вешается на ветку меню, а не на отдельный пункт, при раздаче прав регулярно доставляет много неудобств. Вообще вешать CS на ветку меню, а не на пункт меню — свинство.

Немало неудобств это доставляет и при разработке. Например, поляки в меню Банк сделали "Периодические операции". И повесили на него свой польский ключ. Вот мне нужно создать нечто, чему место с т.з. логики в "Банк\Периодические операции". Какие должны быть мои действия (МБС в очередной раз я уже проклял)?

"
SecurityKey
Mandatory unless:

The NeededAccessProperty is set to NoAccess

-or-

The menu item is used in the Tools menu.

Use the security key that matches its location in the Main menu. For example, the AssetBudget menu item is used in General Ledger > Inquiries. Its security key is LedgerInquiries.
"

Если нужно проверить не все пункты меню — можно согнать их в проект и проверять на уровне проекта.

[gl00mie]

Цитата:

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

Цитата:

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

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

Почему?

Ну я ж уже писал:

Цитата:

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

Могут быть созданы пункты меню, не закрытые ключами контроля доступа, но пользователь, тем не менее, никогда до них не доберется (к примеру, может быть пункт меню, нужный лишь для запуска job'а на сервере, а не на клиенте).

Цитата:

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

ВР требует наличия security key на menu item. Я тоже придерживаюсь такого мнения. Когда SC вешается на ветку меню, а не на отдельный пункт, при раздаче прав регулярно доставляет много неудобств. Вообще вешать CS на ветку меню, а не на пункт меню — свинство.

Целиком и полностью разделяю этот праведный гнев, однако (не сочтите за фамильярдность) "суха теория, мой друг, но древо жизни зеленеет" У меня была определенная проблема, которая напрягала не только меня, но и людей, занимающихся раздачей прав доступа; я решил эту проблему приведенным выше способом. Я знаю, что и в стандартном приложении, и в тех доработках, которые делаю не я, но за которые я отвечаю, встречаются, скажем так, изъяны. И если стандартное приложение можно в контексте рассматриваемой темы исправить "раз и навсегда" (ну, до очередного SP, на который понадобится перейти), то доработки надо контролировать постоянно - и, желательно, с минимальными трудозатратами.

Цитата:

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

SecurityKey Mandatory unless:
The NeededAccessProperty is set to NoAccess
-or-
The menu item is used in the Tools menu.
Use the security key that matches its location in the Main menu.

Вот именно - документация подразумевает, что пункт меню может быть либо в меню Tools, либо в MainMenu, однако, на практике перечень вариантов этими двумя не исчерпывается.

Цитата:

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

Если нужно проверить не все пункты меню — можно согнать их в проект и проверять на уровне проекта.

Очень занимательное предложение с точки зрения того, как можно извернуться, если стоит жесткая установка "не программировать ни при каких обстоятельствах". Теперь внимание, вопрос: как мне "без лишнего шума и пыли" согнать в проект только те пункты меню, которые могут быть видны пользователю через главное меню с учетом наличия отключенных конфигурационных ключей и того, что и конфигурационные ключи, и ключи контроля доступа могут быть привязаны к определенным субменю? Я согласен, что если строго следовать BP и ставить ключи контроля доступа на все создаваемые пункты меню, то таких проблем не возникнет, но в моем случае приходится идти на компромисы и при этом выполнять определенные минимально необходимые требования.

[glibs]

Цитата:

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

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

Неужели так сложно поставить security key на menu item?

По моему опыту нужно просто приучить себя заполнять свойства создаваемых объектов.

В проект достаточно собрать доработки с того слоя, в котором вы работаете. На объектах из стандартных слоев проблем почти нет. И приложение там обычно стабильное.

[Kurol]

Теперь и в акс 3.0 (sp4) работает этот чудный класс!
Спасибо gl00mie !!!