| Data de elaboração | 24/10/2022 |
| Responsável pelo estudo | Rafael Passos dos Santos (Assessor), Lucas de Souza e Sousa (Assessor) |
| Equipe do estudo | André Honório de Andrade Silva (Tecnico), Gezinéia Paula da Costa (Product Owner) Emanuel Rufino Alcantara de Lima (Analista), Lucas de Souza e Souza (Assessor), Rafael Passos dos Santos (Assessor) |
| Alvo | Alpha |
| Origem | Implementação: Identificar se o perfil do servidor é interno ou de usuário externo |
| Objetivo | O presente estudo tem como objetivo identificar se o perfil do servidor é interno ou de usuário externo e qual carta de serviço devo mostrar para esse usuário |
| Documentação correlata | |
| Observações | O presente estudo pretende também pretende levantar as Historias dos cards para a Sprint |
O presente estudo tem como objetivo identificar se o perfil do servidor é interno ou de usuário externo e qual carta de serviço devo mostrar para esse usuário
Existe a necessidade de identificar se o perfil do servidor é interno ou de usuário externo e qual carta de serviço devo mostrar para esse usuário.
Espera-se que, após este estudo, seja possivel identificar se o perfil do servidor é interno ou de usuário externo e qual carta de serviço devo mostrar para esse usuário.
Sabe-se que o alpha terar que ser acessado por usuários externos, que não são servidores publicos, diante disso tornou-se necessario identificar se o perfil da pessoa usando o sistema é servidor ou um usuário externo e qual carta de serviço devemos mostrar para esse usuário.
Solução 1
Após reunião com o Desenvolvedor Anderson Soares do TIME ESQUADRÃO, foi visto que tal informação pode vim da Apis do E-ESTADO.
O qual tem os seguintes bancos de dados em Postgres:
Tabela de servidores, com o campo pessoa_id.

Tabela de usuários, também com o campo pessoa_id

E tabela de usuario escopo, onde vincula uma unidade a pessoa

As informações da Pessoa, pode vim da api de pessoas fisicas do E-estado:

Já a de servidores, pode ser pela nova api de Servidores
Podendo escolher entre duas rotas
A de detalhes que recebe o servidor id

Ou da lista de servidores, que recebe varios parametros
podendo ser o cpf um deles

Se a pessoa tiver dados nessa api, então ela é um servidor, se não, é um usuário externo.
Solução 2
Pode se usar a Api antiga tambem pela seguinte rota

A duas possiveis soluções
Solução 1 - Consulta Api nova do E-ESTADO
| O que | Pontos | Regras | Produto |
| Criar consulta se gestor existe na api do e-estado nova | 5 | Passando o id do servidor (gestor) | Alpha Serviços WEB |
| Criar Consulta se atendente existe api do e-estado nova | 5 | Passando o id do servidor (atendente) | Alpha Solicitações WEB |
| Total | 10 |
Solução 2 - Consulta Api antiga do E-ESTADO
| O que? | Pontos | Regras | Produto |
| Criar consulta se gestor existe na api do antiga do e-estado | 5 | Passando a matricula do servidor (gestor) | Alpha Serviços WEB |
| Criar Consulta se atendente existe na api do antiga do e-estado | 5 | Passando a matricula do servidor (atendente) | Alpha Solicitações WEB |
| Total | 10 |
O cenario informado para implementação é muito incerto, devido a grande quantidade de dúvidas sobre como obter o id do servidor ou sua matricula, pois não se sabe como esse usuario cera cadastrador no sauron
A duvidas tambem sobre o E=ESTADO esta cadastrando o usuário externo e que onformações ele retornaria.
Conclui-se que a solução que trará menos impacto ao sistema será a solução 1.