08.12.2011, 11:47 | #1 |
NavAx
|
Очередной баг в 2009 (права)
Люди! А как вы боретесь с багом, когда на форме присутсвуют обычные кнопки, на которых уровень доступа больше чем просмотр, при этом кнопки замечательно работают, если у пользователя доступ к форме только просмотр?
Замечательно видно на журналах ГК на одобрениях. Переписывать все кнопки на классы и менюайтемы не "джим-бим", но самый верный в условиях глючной 2009. Или вы просто в init() формы дписываете код, по отключению кнопок? ЗЫ. Количество багов в ядре DAX 2009 не поддается пониманию. Как трудно стало жить... |
|
08.12.2011, 11:56 | #2 |
Участник
|
Для себя вывел простое правило, еще с тройки: все важные кнопки, которые должны настраиваться в доступе, переделать на menuitem.
Если не ошибаюсь: если забрать у одной группы права в конкретной форме на конкретную простую кнопку, а пользователя включить в эту группу и в любую другую, не связанную с формой, то кнопки будут доступны, т.к. во второй группе нет явного запрета на те же кнопки. P.S. Одобрением журналов ГК на практике ни разу не пользовался
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
08.12.2011, 12:19 | #3 |
NavAx
|
Проблема в том, что не отрабатывает фильтр по NeededAccessLevel, а это баг. Остальное понятно.
|
|
08.12.2011, 12:28 | #4 |
Участник
|
Цитата:
Цитата:
|
|
08.12.2011, 13:20 | #5 |
MCTS
|
Если не изменяет память, то механизм одобрения на журналах ГК не предполагает явной настройки доступа к кнопкам утверждения с помощью прав в Администрировании.
На названии журнала есть группа пользователей, которая должна выполнять утверждение. Если пользователь принадлежит группе, то кнопка доступна, если не пренадлежит - то кнопка заблокирована. Как-то так.
__________________
Dynamics AX Experience |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
Теги |
ax2009, баг, права доступа |
|
|