Controle de Permissionamento
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:
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 criticar o permissionamento.
Como visto acima, os permissionamentos padrões ( "AEID" ) tem uma sequência de 1 a 4.
Nota: Quando adicionada permissões customizadas, a sequência deve ser seguida a partir da 5a posição de acordo com o que for informado na unit de geração de menus.
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.

Nesse exemplo, o acesso a "aba de licença" do cadastro de clientes recebe o sequencial 5 pois é a primeira opção customizada após a lista padrão.
Vamos rever a instrução do exemplo para entender melhor:
rc_BuildMenuItem( '', 0, 'Clientes tbl:clientes' );
//permissions
rc_BuildMenuItemPermission( '', '<AIED>' ); nessa primeira linha temos de 1 a 4
rc_BuildMenuItemPermission( '', 'Licence Tab' ); logo este segundo ítem é a sequência número 5 da lista de permissões
Através desses exemplos você poderá adicionar e controlar o acesso a qualquer ítem da sua aplicação.
MENU DE REFERÊNCIA
Temos os grupos de menus: BÁSICOS, MOVIMENTO, OUTROS, RELATÓRIOS, FERRAMENTAS.
rc_BuildMenuItem( '', 0, 'Clientes tbl:clientes' );
//permissions
rc_BuildMenuItemPermission( '', '<AIED>' );
O primeiro parâmetro de ambas funções indica o grupo do menu. No exemplo acima foi passado em branco ( '' ) logo assume o Grupo "BÁSICOS" que tb é referenciado com a letra "B".
rc_BuildMenuItem( 'M', 0, Compras tbl:compras' );
//permissions
rc_BuildMenuItemPermission( '', '<AIED>' );
Em "rc_BuildMenuItemPermission" poderia usar "M" já que "rc_BuildMenuItem" foi definido como "M".
Essa configuração acima é permitida a partir da versão 8.4.0.3
Created with the Personal Edition of HelpNDoc: Easily create EPub books