A partir da versão 2.0.0.151 todos os controles( componentes ) descritos no tópico anterior, são criados dinamicamente.


O recurso ainda poderá evoluir ( esse é o propósito do RadCORE ).


Você poderá continuar usando da forma anterior mas vamos ver como proceder a partir da versão informada.



Nas units de formação do MENU PRINCIPAL ( Ex: uMenu_BASICIS ) agora podemos usar a função:


rc_BuildMenuItemPermission( '', '<AIED>' );


Veja o exemplo para adicionar o ítem de cadastro de clientes da forma antiga e com a nova:


     Forma Antiga de acicionar um ítem de menu:


             rc_BuildMenuItem( mm.varA_MenuBasics, iSeqMenu, 'Clientes', 'clientes' );


     Nova Forma:( a partir da versão 5.0 )


             rc_BuildMenuItemPermission( '', '<AIED>' );



O Objetivo da criação da função acima foi para facilitar, mas as duas formas são válidas.



Logo após adicionar um ítem ao MENU, você configura suas respectivas permissões:


     rc_BuildMenuItem( '',  0, 'Clientes tbl:clientes' );

        //permissions

        rc_BuildMenuItemPermission( '', '<AIED>' );

        rc_BuildMenuItemPermission( '', 'Licence Tab' );


Na tabela USUARIOS_RESTRICOES deve haver um campo para receber os parâmetros de permissão de cada opção adicionada. Quando informado o "restriction field" e este não existir, ele será criado.


Vejamos como funciona:


No exemplo anterior: 


rc_BuildMenuItem( '',  0, 'Clientes tbl:clientes' );


não definimos o parâmetro "pRestrictionField", o RadCORE então assume que o campo de controle de permissão é o nome da tabela ou o nome do formulário( o que tiver sido definido, mas, como prioridade, o nome da tabela.


Em nosso exemplo, o segundo parâmetro ( 'clientes' ), é o nome da tabela vinculada a essa opção do menu, então, você deve criar na tabela USUARIOS_RESTRICOES um campo seguindo o modelo:



Na primeira linha de permissão, usando o parâmetro '<AIED>' serão criados os 4 ítens padrões da nova modalidade:


Acess        

Insert

Edit

Delete


Na segunda linha, adicionamos uma permissão específica( 'Licence Tab' ), o que é normal acontecer, pois cada formulário em nossas aplicações podem ter "n" opções de permissão.


Cada elemento adicionado na função rc_BuildMenuItemPermission tem uma sequência numéria para ser usado em conjunto com a função rc_PermissionVerify.


Esta função é quem fará o controle para liberar ou não o acesso a cada ítem definido.


No exemplo acima, um cadastro herdado, com as opções "AIED" terão a seguinte sequência:



Vejamos o frmBaseCRUD :


A função dm_rc.rc_PermissionVerify é a responsável por controlar o acesso em todas as telas e/ou recursos que precisem de crítica.


Sintaxe:

dm_rc.rc_PermissionVerify( 'nome da tela/recurso criticado' , 'tabela' , posicao_criticada ) ;




Cada botão terá uma chamada a função rc_PermissionVerify .


Vejamos o exemplo citado mais acima, no cadastro de clientes.



O acesso a aba de licença do cadastro de clientes recebe o sequencial 6.


Através desses exemplos você poderá adicionar e controlar o acesso a qualquer ítem da sua aplicação.








Created with the Personal Edition of HelpNDoc: Easily create EPub books