Controle de Permissionamento( NEW )
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