Translate

segunda-feira, 4 de março de 2013

AX2009 - Grupos de Usuários - Permissões

Este post está um tanto quanto atrasado tendo em vista que já estamos trabalhando em ambientes de produção com o AX2012 R2 CU1!

Hoje tive a oportunidade de novamente utilizar um recurso extremamente útil na configuração dos Grupos De Usuários do AX2009, nesta oportunidade notei que não publiquei este post, apesar de tê-lo criado a muito tempo. Este post se publicado anteriormente talvez pudesse ter sido útil a muitos incumbidos da árdua responsabilidade de configurar os grupos de usuários para o AX2009.

Mesmo estando atrasado tenho certeza de que muitos AX2009 estão entrando em produção e que muitos já em produção ainda encontram problemas na configuração destes grupos.

Por esta razão segue abaixo uma dica de grande utilidade para este trabalho.

A criação e configuração inicial destes grupos de usuários pode ser vista neste post, Apesar de ser para a versão 4.0 o conceito continua o mesmo pelo menos na versão 2009!

Durante a configuração e testes dos grupos de segurança é comum encontrar erros de acesso a determinadas tabelas, e em sua grande maioria, estas tabelas se esforçam muito em se esconder completamente da nossa visualização!

Existem ferramentas como o Security Profiler Tool mostrado neste post do Brandon George.

Existe também o método força bruta, ou seja, procure até encontrar!

Um método que acho extremamente interessante, útil e, na minha opinião, muito mais fácil é a consulta via AOT. Este método dispensa ferramentas adicionais e basta ter permissão de acesso a AOT.

Na imagem abaixo temos um erro comum na configuração de permissões no AX2009. Criei em minha VM o grupo de segurança Teste1 e vinculei a este grupo o usuário de nome Teste1 (usuário e grupo como mesmo nome sim!). concedi a este grupo permissão de "controle total" e "em cascata" no modulo de contas a receber. Ao acessar o AX e tentar consultar o formulário de "Detalhes do Cliente" do modulo de "Contas a Receber" ainda assim eu recebi a mensagem de erro abaixo.


A mensagem diz que o usuário "Teste1" não possui permissão para acessar a tabela "Clientes". É comum que estas mensagens exibam também o nome (Label) da tabela, e é exatamente este o nome com o qual vamos trabalhar. No caso da mensagem acima o nome da tabela é "RBOCustTable".

Lembrem-se de que este método é valido para qualquer tabela, mas que é necessário obter o nome exato da tabela para que possamos localiza-la na AOT.

Agora abra a AOT do AX e expanda a opção "Data Dictionary" > Tables e localize a tabela "RBOCustTable". Clique com o botão direito sobre ela e selecione propriedades.


Vejam que na imagem acima selecionei o nome da tabela, RBOCustTable, Selecionei também a Label Cliente (Varejo) que é exibida na mensagem de erro e também selecionei a "SecurityKey" desta tabela.
Até o momento temos as seguintes informações, a tabela é a Clientes (varejo) e sua "SecutiryKey" é a "RBOTables". Precisamos agora encontrar esta "SecurityKey" e verificar suas propriedades.

Ainda na AOT expanda agora as opções "Data Dictionary" > "Security Keys" e abra as propriedades da SecurityKey "RBOTables".

Agora temos a SecurityKey, na imagem acima podemos ver a "Label" que é "Tabelas". Isto significa que a tabela "Clientes (Varejo)" esta dentro das tabelas de algum modulo, mas qual é este modulo tendo em vista que todos os módulos do AX possuem a opção tabelas? A resposta está na opção "ParentKey". Vejam que a ParentKey é a "RBO". Ainda nas SecutiryKeys localize esta ParentKey e veja qual a Label dela.

A Label da ParentKey "RBO" é a "BackOffice". E oque isso significa? este é o modulo do AX no qual temos que conceder a devida permissão!

Vamos rever os passos executados aqui:

Vimos que o erro estava na falta de acesso a tabela "Clientes (Varejo)" ou "RBOCustTable"
Localizamos e visualizamos as propriedades da tabela "RBOCustTable"
Localizamos a SecurityKey da tabela "RBOCustTable". "SecurityKey = RBOTables"
Localizamos a SecurityKey "RBOTables" e localizamos a "Label" e "ParentKey" dela.
Localizamos a "ParentKey" e vimos o nome da "Label" dela.

Desta forma chegamos a seguinte conclusão:

Tabela com falta de permissão:
RBOCustTable. Sua Label é "Clientes (Varejo)

A SecurityKey da tabela com problema é a:
RBOTables. Sua Label é a "Tabelas"

A "ParentKey" da "SecurityKey" é a:
"RBO". Sua Label é "BackOffice".

E desta forma encontramos exatamente onde está o problema de permissão.

BackOffice > Tabelas > Clientes (Varejo).

Basta agora conceder a devida permissão no caminho acima e pronto.


E assim concedemos permissão ao usuário na tabela correta!

Espero ter sido claro o suficiente em meu post.

Caso tenham duvidas referente a este processo por favor entrem em contato comigo!

Nenhum comentário:

Postar um comentário