How to restrict the applicant from approving his own request?

[Matheus Lima]

Boa tarde, comunidade.
Haveria a possibilidade de restringir via fluxo, que o solicitante possa aprovar sua solicitação (no caso ele seria um dos aprovadores desta determinada solicitação junto com outros mais) ?

[Carlos Camacho]

Olá Matheus,

Do ponto de vista do planejamento da arquitetura não é muito comum uma persona que cadastra também ser a persona que aprova. São funcionalidades bem distintas. 

Supondo que está tudo certo e a persona que cadastra realmente faz parte do grupo de aprovadores, um workaround seria inibir a lista de aprovadores caso o usuário logado esteja visualizando um registro que ele mesmo cadastrou. 

Reforçando: workaround não é a solução definitiva. Apenas paliativa enquanto você pensa na solução ideal. 

Vamos detalhar a ideia: 

1) Todo registro tem um campo chamado sys_created_by que armazena o nome do usuário responsável pela criação do registro;

2) No front-end (lado do cliente) você tem acesso a uma API chamada Glide User que possui algumas informações do usuário logado. Dentre elas está o nome na propriedade userName. 

E se a gente criar um Client Script do tipo onLoad (é executado sempre que o formulário é aberto) que compara estes dois campos e, caso sejam iguais, simplesmente esconde a lista relacionada dos Aprovadores? Eu avisei que era um workaround, não avisei?

Muito bem... para saber o nome da sua related list criada para a sua tabela você pode acessar a plataforma e ir em System UI > Related lists

Com esse nome em mãos, o seu Client Script ficaria algo como: 

function onLoad() {
   
   var criadoPor = g_form.getValue('sys_created_by');
   var userLogado = g_user.userName;

   if (criadoPor == userLogado) {
      g_form.hideRelatedList('nome da sua related list aqui');
   }

}

Observações finais:

Para obter o valor do campo sys_created_by ele deve estar no formulário. Você pode deixá-lo somente leitura ou até escondê-lo, mas ele deve existir no form.

[Vivi Brasil]

Olá Matheus,

Como o Carlos Camacho bem colocou, não seria um cenário comum. Vale ponderar se o esforço e o nível de customização para atingir esse objetivo, e a manutenção futura, compensaria pelo número de incidências ou de cenários de desvio em que isso poderia ocorrer (se não existiria outra forma de se contornar).

Para impedir por completo que a aprovação ocorra, vejo que seriam necessárias ao menos duas ações:

• ACL: Alterar as regras de restrição de acesso (ACL - Access Control List), da tabela sysapproval_approver, para validar que o aprovador deve ser diferente por ex. do "Requested for".
  
  Precisaria alterar pelo menos a ACL de write do campo State do registro de aprovação (sysapproval_approver.state). Mas essa alteração é bem delicada, até por ACL ser algo bem sensível, precisaria testar muito bem, inclusive porque a tabela de Aprovações é utilizada por outros registros (não só para Request, mas também para Change, Knowledge Article, dentre outros...). Precisaria condicionar de uma forma que esta validação adicional só ocorresse para registros de aprovação, cuja tabela de origem é a de request (source_table=sc_req_item, por exemplo), e para todos os demais registros de aprovação, continuaria valendo a restrição nativa.
  
  

• Ações para prevenir que a aprovação seja gerada: colocar validações nos locais em que o usuário pode selecionar um aprovador, se por exemplo há uma Variável em que ele selecione os Gerentes e ele mesmo é Gerente, deveria existir uma condição no reference qualifier da variável, para não exibir o próprio usuário logado. Mas claro que dependendo da situação, uma Aprovação por Grupo como você colocou, se o Grupo aprovador já estiver definido no fluxo, pode ser mais complicado impedir que a aprovação seja gerada, pois ela será gerada para todos os membros daquele Grupo.
  
  Estas ações adicionais seriam importantes para evitar que a aprovação seja gerada (evitar que seja criado algo para ele mesmo na tabela sysapproval_approver), pois por mais que você trate via ACL e o aprovador não consiga aprovar o registro aberto por ele mesmo, a ACL só vai gerar a mensagem de restrição de acesso quando ele for tentar aprovar de fato, mas não irá impedi-lo de ver os registros pendentes em todos os locais em que o My Approvals é referenciado (na related list da RITM como o Carlos Camacho mencionou, mas também no módulo My Approvals dentro do application menu do Self-Service da plataforma, no My Approvals do Portal, no My Approvals do app Now Mobile... enfim, em todos os locais em que o My Approvals pode ser usado e exibido na instância).
  
  Além disso, por mais que ele não consiga aprovar (pois a ACL o impedirá de mudar o status do registro de aprovação), não o impedirá de receber notificações da aprovação gerada (ele receberá uma notificação dizendo que há algo pendente dele aprovar, mas quando ele tentar aprovar, seja por e-mail, seja na plataforma, a ACL o impedirá de aprovar).

Seria preciso avaliar e testar bem os cenários, e ponderar que esta será uma alteração a manter no futuro (por isso ponderar se realmente é algo que precisa ser realizado).

Talvez outra abordagem seria separar Grupos Aprovadores de Grupos de Suporte... assim você garante que somente os membros de Grupos Aprovadores podem aprovar (somente Grupos aprovadores estariam nos fluxos), mas enfim, depende muito do cenário.

----
Edit: adicionei em outro comentário mais abaixo na thread, em resposta ao Matheus, uma outra opção, de uma Business Rule que seja executada no before e impeça a aprovação ou rejeição (aborte a ação durante o update do campo State na tabela sysapproval_approver, somente para Requested Item), mas seria preciso validar bem os locais em que a aprovação ocorre (inclusive se por Email funcionaria bem, caso o Inbound Email Action ou outro recurso esteja sendo utilizado para permitir aprovar ou rejeitar a requisição por e-mail).
----

Obrigada!

[Vivi Brasil]

PS: em uma implementação tivemos que alterar as ACLs de aprovação por outro motivo, e por isso digo que os testes são importantes, nós tivemos que testar muitos cenários para confirmar que estava tudo dentro do esperado.

Outra coisa que tivemos que fazer, foi garantir que o Grupo aprovador não esteja vazio ou inválido (que o Grupo Aprovador possua membros, que os membros estejam ativos e possuam a Role que os permita aprovar), pois caso o Grupo esteja sem membros, o fluxo acaba gerando um bypass. Estes requisitos nós tratamos antes de enviar a aprovação (há um Script Include que faz todas estas validações e retorna para o fluxo, antes da aprovação ser de fato gerada pelo fluxo). Mas foi algo bem particular, para de fato garantir que a aprovação não gere um bypass (não é comum e de fato foi necessária no cenário, mas em outros cenários, valeria ponderar outras alternativas, para garantir que nenhum grupo aprovador esteja vazio).

[Luiz Lucena]

Muito bem lembrando, @Vivi Brasil, sem alterar ACLs, o mais correto seria criar aprovação do gestor da pessoa. 

Daí, independente se ele for também um aprovador ou não, o flow pediria aprovação do gestor do solicitante.

Mas lógico, isso depende muito das regras de negócio, que variam muito de empresa pra empresa.

Achei que tinha algo parecido aqui, mas me enganei.

No seu fluxo, talvez você terá primeiro que validar se o solicitante pertence ao grupo de aprovadores, e então inibir a notificação pra ele, como o Carlos sugeriu. Porém, acho que o script acima só funcione no backend, não sei se funcionará no portal de serviços ou mobile.

[Vivi Brasil]

Isso mesmo @Luiz Lucena , bem colocado. O ponto de inibir somente na related list da request, é que em qualquer outro local a aprovação poderá ser realizada (mesmo na própria plataforma, no application menu e módulo do Self-Service >> My Approvals, o usuário conseguirá ver e aprovar), por isso creio que é um workaround a ser considerado se o cenário assim o permitir, já a ACL é o jeito mais seguro, mas claro que possui seus complicadores.

Abraço!