#516 [FEAT]: Checagem de permissão em conformidade com novo protocolo de controle de acesso da API

[IosBonaldi]

As funções aqui apresentas tem por objetivo aprimorar as checagens de permissão no conjunto App/API, , em conformidade com as novas funcionalidades implementadas na API via issue 139. Com isso, ensejou-se centralizar responsabilidades na API, removendo checagens redundantes e validando checagens existentes;

As alterações mais relevantes são apresentadas abaixo:

Compatibilização de checagem de permissões em conformidade com API:

• A partir da aprovação da issue 139, a API passará a retornar, junto a cada objeto de interesse, um objeto contendo um conjunto de diretivas sobre quais ações o usuário atual pode exercer em relação ao objeto, i.e., se pode editá-lo, excluí-lo, visualizar seus detalhes, etc. Isto permite que a API centralize a checagem destas permissões, sem que o front interagindo com ela necessite conhecer as regras de negócio envolvidas;
• Essencialmente, objetos de interesse são acompanhados de uma propriedade actions, dotada de propriedades booleanas tais quais [permission...] toUpdate, toDelete, toGetAnswers, etc;
• Em função disto, buscou-se remover o maior número possível de checagens de permissão realizados manualmente no front, substituindo por checagens às diretivas retornadas pela API. Foram substituídas checagens de edição [1], exclusão [2], aprovação [3], e similares;
• Destaca-se que checagens de permissão de criação foram apenas revisadas [4], mas mantidas. Isto se deu pois antes da criação não há objeto de interesse para o qual a API possa retornar diretivas e, no momento, endpoints específicos para solicitação de diretivas não estão previstos (as diretivas são retornadas junto à endpoints existentes);
• No caso das checagens de permissão de visualização, a abordagem foi de remoção [5], uma vez que tais checagens são implícitas nos endpoints da API. Assim, é trivialmente observável que não há permissão de visualização quando a solicitação é rejeitada, de maneira que uma checagem prévia é redundante, diminui a modularidade e pode conduzir a erros;

Simplificações gerais de código:

• Alteração de textos visíveis para o usuário, nomes de funções e opção de remover chaves e quebras de linha não necessárias visando a redução do código fonte e, possivelmente, facilitar sua legibilidade. Meramente visual, nada muito embasado [6].

Correções em tratamento de erros e similares:

• Alertas e disparos de erro catastrófico foram checados e corrigidos, de maneira que alguns casos que antes disparavam erro agora permitem que o usuário prossiga com alertas e vice-versa [7];
• Dada a difusão da página de erro, optou-se por inserir uma opção de voltar ao início, sem necessariamente desautenticar o usuário [8];