As solicitações de acesso tratam uma necessidade de acesso como uma gestão rastreável. O GovFrame contempla carrinho de solicitações, casos de Workflow, tarefas, decisões, provisionamento e evidências. Uma gestão pode agrupar itens e admitir resultados parciais.
A solicitação obtém seu contexto do objeto solicitado — por exemplo, uma tabela, um dashboard, um conjunto de dados ou outro destino permitido — e é vinculada a um caso de Workflow. O objeto e suas associações determinam o contexto de negócio; a solicitação não contorna regras de empresa, associação, módulo, capacidade ou escopo.
Antes de começar
- Papel: um Usuário pode participar das solicitações autorizadas pela política da sua empresa. A gestão administrativa de acessos, associações, solicitações e provisionamento requer a capacidade
access.manage, própria do Administrador no contrato atual. Quem decide uma solicitação também deve ter a responsabilidade que a empresa configurou para o caso e estar autorizado no respectivo contexto. - Módulo: os componentes de Workflow envolvidos devem estar operacionais para a empresa. Os módulos configuráveis são validados na interface e no backend; desativar um deles não elimina automaticamente seus registros, mas impede continuar operando com sua função.
- Pré-condições: o destino deve existir na empresa e ser identificável como objeto solicitado. Verifique sua relação com a taxonomia, os responsáveis e o escopo antes de processá-lo. A associação ativa do solicitante e dos participantes continua sendo necessária.
As visualizações temporárias do usuário são somente para leitura, exceto pelas operações de Solicitações de acesso expressamente permitidas. Elas não ampliam as permissões do catálogo nem permitem alterar a empresa ou o escopo pelo navegador.
Percurso recomendado
- Defina a necessidade com o objeto correto. Localize o ativo, a tabela, o dashboard, o conjunto de dados ou outro destino admitido pela política da empresa. Verifique o que está sendo solicitado e qual é seu contexto. Não infira uma relação técnica apenas porque dois objetos compartilham um nome ou Domínio.
- Agrupe os itens relacionados. Use o carrinho para reunir as solicitações que devem ser tratadas na mesma gestão. Mantenha a justificativa e o escopo de cada item distinguíveis, pois a decisão pode não ser idêntica para todos eles.
- Crie o caso e organize o trabalho. A solicitação é vinculada a um caso de Workflow, a partir do qual são acompanhados as tarefas, os participantes e a decisão. O percurso é orientativo: o estado atual documenta os componentes funcionais, não um formulário fixo, uma lista pública de etapas ou nomes de estados.
- Decida com evidências. Os responsáveis autorizados analisam a solicitação, aplicam as regras de acesso da empresa e registram a decisão e as evidências disponíveis. Pode haver aprovação parcial e tratamento de mascaramento quando o caso exigir; a documentação não define uma política universal de mascaramento nem seus valores.
- Acompanhe o provisionamento. Quando uma decisão exigir provisionamento, mantenha-o como parte rastreável da gestão e verifique as evidências associadas. A existência dessa fase não confirma que o acesso seja criado automaticamente em um sistema externo: qualquer integração e sua execução efetiva dependem da configuração da empresa.
- Revise o resultado por item. Confira se as tarefas, a decisão, as possíveis restrições e as evidências correspondem a cada destino solicitado. Se o objeto tiver relações com contratos, produtos, regras ou fontes técnicas, use o mapa de relações para fundamentar a análise sem inventar dependências.
Exemplo sintético. Uma analista reúne em uma solicitação um dashboard e um conjunto de dados associados ao Domínio Comercial. O caso é encaminhado aos responsáveis configurados. O dashboard é aprovado e o acesso ao conjunto de dados é condicionado a uma medida de mascaramento documentada na mesma gestão. O exemplo ilustra uma decisão parcial; não descreve campos nem telas obrigatórias.
Resultado esperado
A empresa dispõe de uma gestão que conecta o solicitante e os destinos requeridos ao caso, às tarefas, à decisão, ao provisionamento quando aplicável e às evidências. O resultado deixa visível o que foi resolvido para cada item, sem confundir uma aprovação de negócio com a criação técnica automática de uma permissão externa.
A rastreabilidade é mantida dentro da empresa efetiva. O backend deriva a empresa da sessão e verifica a associação, o módulo e as autorizações; a alteração de identificadores ou parâmetros no cliente não deve habilitar o acesso a objetos de outra empresa.
Limites do comportamento atual
- Não são publicados estados das solicitações, prazos, transições, formulários, catálogos fechados de destinos nem etapas exatas de telas, porque não estão definidos como contrato funcional comum.
- O carrinho e a aprovação parcial não substituem as regras de escopo. Ter uma tarefa atribuída não autoriza operações alheias ao objeto ou Domínio correspondente.
- O GovFrame documenta o provisionamento e as evidências na gestão, mas não permite presumir que um conector ou sistema de destino execute permissões automaticamente.
- Se a decisão se apoiar no SQL de uma Regra de qualidade, o SQL só poderá ser gerado quando houver um Campo físico associado e um dialeto configurado. A solicitação não executa esse SQL automaticamente.
