AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.09.2010, 13:06   #1  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
права на кнопку
Добавлена кнопка(именно button), на стандартной форме . К кнопке привязан ключ LedgerMisc и к MenuItemу, вызывающему форму, тоже. Можно ли как-нибудь сделать так, чтобы по умолчанию доступа к кнопке не было у юзеров, даже если есть все права на ключ LedgerMisc. То есть чтобы кнопка была доступка если только дали явно доступ к кнопке через Настройку прав доступа.
Я пока вижу либо создание нового ключа и повесить его на эту кнопку (но мы стараемся не создавать новых ключей , тем более ради одной кнопки), либо кодить - искать по пользователю, даны ли ему права на кнопку.
Есть альтернативные варианты? Может, стоит создать отдельную группу пользователей и запихнуть ее в настройки и проверять пользователей на принадлежность ей? Чем такой вариант лучше, чем создание ключа отдельного.
Старый 21.09.2010, 13:33   #2  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2156 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Почему кнопка (именно button), а не menuitem?

Все зависит от подхода настройки прав доступа. Я предпочитаю всё отключать, и только нужное разрешать. Поэтому, как правило, на самих ключах доступа прав не бывает.
__________________
Ivanhoe as is..
Старый 21.09.2010, 14:46   #3  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
почему button - вопрос риторический... но в данном случае, вроде, не должно играть особой роли, тк хоть это и не стандартный подход, но аксапта позволяет ключ повесить на нее и в дереве настройки прав доступа кнопки отображаются.
Старый 21.09.2010, 16:29   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,323 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от IKA Посмотреть сообщение
почему button - вопрос риторический... но в данном случае, вроде, не должно играть особой роли, тк хоть это и не стандартный подход, но аксапта позволяет ключ повесить на нее и в дереве настройки прав доступа кнопки отображаются.
Именно это как раз и играет роль. Сделайте MenuItemButton и будет счастье. С ключом - не заморачивайтесь - считайте - что ключи нужны исключительно для группировки объектов, на которые дается доступ. Я конечно утрирую и, безусловно, можно и нужно менять доступ на ключах у ряда пользователей. Но в данном случае (при выборе между button и menuitembutton) представьте себе - что на ключах доступ менять нельзя.
__________________
Возможно сделать все. Вопрос времени
Старый 21.09.2010, 17:38   #5  
vallys is offline
vallys
Developer
 
146 / 108 (0) +++++
Регистрация: 18.01.2005
Цитата:
Сообщение от IKA Посмотреть сообщение
Добавлена кнопка(именно button), на стандартной форме . К кнопке привязан ключ LedgerMisc и к MenuItemу, вызывающему форму, тоже. Можно ли как-нибудь сделать так, чтобы по умолчанию доступа к кнопке не было у юзеров, даже если есть все права на ключ LedgerMisc.
Сталкивались с аналогичной задачкой. Но не просто для кнопок, а для более общего случая – для таблиц, полей, пунктов меню и т.д. Ситуация была аналогичная – при создании нового элемента в репозитарии (например кнопки), к нему автоматически имели доступ (соответствующего уровня) все пользователи, которые имели доступ к ключу доступа, который был прописан для этого элемента. Происходит так, потому что в аксапте (при проверке прав) используется принцип: все что не запрещено - разрешено. Поэтому, если для пункта меню (кнопки, таблицы, ...) явно не прописать запрет доступа, то он будет доступным всем пользователям, у кого есть соответствующие права на ключ безопасности, указанный для пункта меню; если ключ безопасности не указан – всем пользователям. У себя мы решили задачу следующим образом: при импорте проектов автоматически закрывается доступ ко всем «новым» элементам репозитария (определенных типов). Также добавили пункт контекстного меню «убрать доступ» для объектов, которые создаются руками, если возникает такая необходимость.

Посмотреть/изменить права для конкретного объекта возможно (с ньюансами) с помощью формы от Raven Melancholic: установка прав

Права лежат в таблицах AccessRightsList, SysSecurityFormTable, SysSecurityFormControlTable. Работа с AccessRightsList через классы, как указано в примере тут или напрямую. С SysSecurityFormTable, SysSecurityFormControlTable - через класс SysSecurityFormSetup.

P.S. SysSecurityFormTable + SysSecurityFormControlTable - права для контролов форм. AccessRightsList - для всего остального.

Последний раз редактировалось vallys; 21.09.2010 в 17:59.
Старый 21.09.2010, 18:00   #6  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,323 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от vallys Посмотреть сообщение
Происходит так, потому что в аксапте (при проверке прав) используется принцип: все что не запрещено - разрешено.
Не совсем так. Все разрешения наследуются от ключа, к которому относится данный элемент. Поэтому при добавлении нового пункта меню доступ на него наследуется от ключа, к которому настроен доступ. Т.е. если доступа не было - он и не появится. Если был - появится.
Но наследование можно разорвать, изменив уровень доступа вручную. В этом случае в таблице AccessRightsList создастся запись, относящаяся к данному элементу. В этом случае изменение доступа к ключу не повлияет на уровень доступа к элементу (пункту меню, таблице).
К сожалению, есть примеры, когда на ключ вешают контрольки или само меню - в результате чего - невозможно пользоваться функционалом без включения самого ключа. Но в целом этим не пользуются.
__________________
Возможно сделать все. Вопрос времени
Старый 21.09.2010, 18:12   #7  
vallys is offline
vallys
Developer
 
146 / 108 (0) +++++
Регистрация: 18.01.2005
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Не совсем так. Все разрешения наследуются от ключа, к которому относится данный элемент. Поэтому при добавлении нового пункта меню доступ на него наследуется от ключа, к которому настроен доступ. Т.е. если доступа не было - он и не появится. Если был - появится.
Да, конечно. Видимо я не совсем понятно высказался. "Не запрещено" - не только для элемента, а в целом в соответствии с политикой проверки прав Аксаптой (см. рис., источник: Microsoft TechNet - Manage security permissions for user groups and domain combinations)
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Но наследование можно разорвать, изменив уровень доступа вручную. В этом случае в таблице AccessRightsList создастся запись, относящаяся к данному элементу. В этом случае изменение доступа к ключу не повлияет на уровень доступа к элементу (пункту меню, таблице).
Да. Именно потому что для новых объектов нет записей в AccessRightsList - для них используются права соответсвующего ключа доступа, если таковые имеются.
Миниатюры
Нажмите на изображение для увеличения
Название: Aa570104_MenuItemAccessFlow(en-US,AX_50).gif
Просмотров: 509
Размер:	13.8 Кб
ID:	6165  

Последний раз редактировалось vallys; 21.09.2010 в 18:25.
Старый 21.09.2010, 21:22   #8  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Именно это как раз и играет роль. Сделайте MenuItemButton и будет счастье. С ключом - не заморачивайтесь - считайте - что ключи нужны исключительно для группировки объектов, на которые дается доступ. Я конечно утрирую и, безусловно, можно и нужно менять доступ на ключах у ряда пользователей. Но в данном случае (при выборе между button и menuitembutton) представьте себе - что на ключах доступ менять нельзя.
Какую роль играет menuItemButton или это Button? Вы имеете ввиду, что права на menuitembutton непосредствеено в дереве Main menu можно настроть, а с кнопками - только через security key view? Проблема, что у нас много доменов и много групп пользователей, поэтому хотелось бы что-нить придумать, чтобы не перенастраивать права везде, а просто сделать для всех, кроме некоторых пользотетелей, эти кнопки недоступными.

Последний раз редактировалось IKA; 21.09.2010 в 21:29.
Старый 21.09.2010, 21:34   #9  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,323 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от IKA Посмотреть сообщение
Проблема, что у нас много доменов и много групп пользователей, поэтому хотелось бы что-нить придумать, чтобы не перенастраивать права везде, а просто сделать для всех, кроме некоторых пользотетелей, эти кнопки недоступными.
Так воспользуйтесь уже данным советом.
Цитата:
Сообщение от vallys Посмотреть сообщение
Посмотреть/изменить права для конкретного объекта возможно (с ньюансами) с помощью формы от Raven Melancholic: установка прав
Делаете MenuItemButton и для этой кнопки с помощью вышеуказанной формы настраиваете права только тем кому нужно. Сразу по доменам и группам пользователей.
Кстати - если у Вас количество групп пользователей сопоставимо с количеством пользователей или превышает их - то разумнее каждому пользователю сопоставить свою индивидуальную группу. Упростите себе работу по настройке прав.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 21.09.2010 в 21:40.
Старый 22.09.2010, 10:22   #10  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2156 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Эх, как часто приходится встречаться с таким подходом: сделали изначально неверно (по незнанию, ошибке или еще почему), а потому всеми силами держаться за это решение, плодя проблемы и ошибки, ставя костыли.

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

Мой совет: признайте проблему, найдите ресурсы и сделайте настройку прав доступа по-нормальному. Тем более что это намного проще, чем делать реинжиниринг процессов или перевнедрение. Разработайте правила выделения групп и их настройки, привидите доработки к стандартному виду - настройка прав доступа ТОЛЬКО через меню-айтемы. Не давайте, по возможности, права на сами ключи - только на объекты, к ним привязанные. Введите регламенты настройки - кто и на основании каких документов вносит изменения в права / назначает права пользователям, как выполняются доработки (с учетом назначения прав), в каких документах описаны правила управления доступом и т.п.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: sukhanchik (5), gl00mie (7).
Теги
menuitem, security, права доступа

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Права доступа и переименование andriy_s DAX: Администрирование 2 20.07.2010 13:34
Права RLS и складские аналитики. Выбор партии вешает клиента bobski DAX: Функционал 4 22.09.2009 09:08
Права группы пользователей Apollon33 DAX: Администрирование 8 17.01.2008 14:16
Не сохраняются права группы madproger DAX: Администрирование 4 02.10.2006 01:14
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:38.