Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
Controlando o acesso
Gerenciando a Entrada ao Sistema
Quando pensamos em controlar o acesso dos usuários aos sistemas que desenvolvemos, já imaginamos o trabalho que vai dar... Realmente, ele se tornará imenso se tivermos que alterar todos os formulários, colocando um código (mesmo que pequeno) nos eventos de cada objeto presente nestes mesmos formulários. Vamos inovar um pouquinho, saindo do controle que veio das linguagens de programação para DOS, onde controlávamos o acesso apenas para as funções Inclusão, Alteração, Exclusão e (quando muito) Consultas/Relatórios. Como estamos no ambiente Windows, podemos estender este controle para os objetos do formulário.
Não vamos colocar aqui a interface para permitir ou negar o acesso a qualquer um destes controles. Isto fica a cargo de cada um, e, como não poderia deixar de ser, cada um tem uma forma própria de fazer. Mas podemos adiantar que, diante do que propomos aqui, não fica difícil imaginar 'como' fazer. Ficaremos somente com a parte de como habilitar ou desabilitar os controles de cada formulário, de acordo com quem está logado no sistema.
Comecemos desenhando o nosso controle. Não o faremos diretamente para o usuário, mas sim para um "Perfil" de usuários. Suponhamos que temos os perfis: "GERENTE" e "VENDEDOR", sendo que um perfil tem acesso completo ao sistema e o outro a apenas alguns controles.
O fato de um perfil não ter acesso a um determinado controle pode fazer com que o usuário não possa usar o controle (quando nós o desabilitamos) ou não possa ao menos ver que o controle existe (tornamdo-o invisível).
Para o nosso exemplo, foram criadas duas tabelas (em Paradox, mesmo). Uma delas chama-se "USERS.DB", e possui a seguinte estrutura:
Nesta tabela estão cadastrados os usuários do sistema. Obviamente, é um cadastro incompleto (falta, entre outras coisas, a senha de acesso, etc.), portanto, não leve isto em consideração. Veja que temos o campo do perfil do usuário (ACS_PERFIL).
A outra tabela chama-se "ACESSO.DB" com a seguinte estrutura:
Nesta tabela estão cadastradas as permissões de acesso ao sistema. Logicamente, poderia haver uma outra tabela apenas para o perfil. Porém, estaríamos complicando muito, por isso isto é apenas um exemplo.
O campo ACS_GRUPO serve para armazenar o nome do formulário, assim como o campo ACS_SUBGRUPO serve para armazenar o nome do objeto que está associado ao formulário. Já o campo ACS_ENABLED trabalha armazenando a possibilidade do usuário ter este objeto habilitado (valor "S") ou não (valor "N"); por fim, o campo ACS_VISIBLE serve para armazenar a visualização deste campo por parte do usuário, sim (valor "S") ou não (valor "S").
É claro que estes campos poderiam ser do tipo "Boolean", mas não foram feitos desta forma pois alguns bancos de dados (Interbase, SQL Server, etc) não possuem este tipo para seus campos. Ficaram então como alfanuméricos com um byte ("S" = True ou "N" = False)."
[...] continue lendo...