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