Descrição (Como usuário gerente de algum grupo, eu quero poder cadastrar meus grupos para para que os usuários pertencetes a ele possam reportar e me trazer insights?)

Critérios de aceite

• Model de Manager;
• Manager deve ser autenticável, assim como User e Admin que já existem na API ;
• Usar o devise.
  

Descrição

A aplicação vai possuir dois tipo de managers, um para cuidar de instituição (group_manager) e um para cuidar e conteúdo como sindromes, sintomas, usuários, porcentagens e outros, este chamado manager.

A arquitetura atual possui um manager que deve ser renomaeado para group_manager e depois deve ser feito o manager.

Critérios de aceitação

• Existe classe manager, como explicado acima.
• Existe classe group_manager, como explicado acima.

Descrição

Acrescentar o campo de UF para que seja possível adicionar a unidade de federação a que a instituição está localizada.

Essa alteração também é necessária para o funcionamento do feature descrito na Issue #58 do repositório guardioes-app.

Critérios de aceite

• campo UF na tabela school_unit;

Descrição

Alguns reportes estão saindo com a data errada pois o fuso horário da API não está de acordo com o fuso horário de Brasília.

Descrição

Como USUARIO, preciso de um acesso mais rápido ao dashboard.
Como PO, preciso diminuir os custos dos servidores.

Hipóteses

A priori, um dos possíveis gargalos para a alta latência de resposta parece ser a query que retorna os pinos no mapa. Outras possibilidades também não estão descartadas. Por isso, o primeiro passo dessa issue é testar e documentar testes de hipóteses à respeito desses gargalos.

Possíveis soluções

Soluções que independem da fonte do problema:

• Tornar as queries para a base de dados assíncrona, sendo feitas simultaneamente, os custos de tempo de I/O diminuem.

Caso o gargalo se confirme sendo o mapa:

• Diminuir o número de hits de surveys para as ultimas N da base de dados ou por tempo. (N pode ser 500, por exemplo)
• Implementar um cache que se atualiza a cada N horas/minutos, as queries retornariam o resultado do cache. (N pode ser uma hora)
• Retornar apenas os casos com sintomas, e talvez alguns sem sintomas para completar.

Critérios de aceitação

• Testar e documentar nessa issue hipóteses à respeito dos gargalos.
• Implementar uma ou mais das soluções anteriores de forma a diminuir o tempo de resposta e consumo de processamento para níveis adequados.

Descrição

Ao resetar a senha por código no email, ela não é alterada.

Passo a Passo

Passo a passo para se reproduzir o bug:

1. Em '/email_reset_password' enviar email.
2. Em '/show_reset_token' inserir código recebido por email.
3. Em 'reset_password', inserir token recebido no passo anterior junto a nova senha.
4. A senha porém não é resetada.

Comportamento Esperado

A senha deve ser alterada para a senha escolhida.

Estudei os end

Descrição

Adicionar campos de cidade, estado , país de residencia, número de identificação, grupo de risco e instituição.

Descrição

Precisamos de um forma de subir um ambiente de staging para testarmos as features da API

Tarefas

• Entrar em contato com o responsável pela infra no Lappis para sabermos como será feito o deply
• Subir de fato a API no servidor

Critérios

• API deployada

Buscar soluções para conseguir enviar emails sem uso da API de Terceiros.

Atualmente é usada a API do SendGrid para emails de redefinição de senha, porem ela possui um elevado custo monetário.

Critérios de Aceite

• Documentação da Solução

Observar os métodos Create e caso for possível torna-lo assícrono, por meio de jobs , como no tópico The delivery of the response has unnecessary dependencies .
A avaliação se há ou não possibilidade de torna-lo assícrono deve ser levado em conta principalmente as necessidades do App.

Critérios de aceite

• Métodos de create assincronos;
• Jobs criados e testados;
• Retornar a mesma resposta caso seja necessário.
  

Descrição

Quando se cria uma sindrome com sintomas ainda não criados no DB o atributo code dele vai duplicado.

Passo a Passo

Passo a passo para se reproduzir o bug:
1 - Enviar essa request para sindromes diferentes mas com mesmos sintomas

curl --location --request POST 'localhost:3001/syndromes' \
--header 'Accept: application/vnd.api+json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIiwic2NwIjoiYWRtaW4iLCJhdWQiOm51bGwsImlhdCI6MTU5MzgwOTYzMSwiZXhwIjoxNTk2NDM5Mzc3LCJqdGkiOiI3ZTcwZGZkNS0xZGI3LTQ0ODUtYjZkMy1kZTRkZjNlMTIwYzkifQ.NVx5sNDcmWXJ5mVbUoiwsrYqcTMOrZZLVWZTRkVRHb0' \
--data-raw '{
	"syndrome": {
		"description": "Síndrome Gripal",
		"details": "Detalhes sindrome gripal",
		"symptom": [
			 {
					"description": "Dificuldade para Respirar",
					"code": "DificuldadeParaRespirar",
					"priority": 1,
					"details": "Dificuldade Para Respirar",
					"app": {
						"id": 1,
						"app_name": "Guardioes da Saude",
						"owner_country": "Brazil"
					}
			 },
			{
				"description": "Febre",
				"code": "Febre",
				"priority": 1,
				"details": "Febre",
				"app": {
					"id": 1,
					"app_name": "Guardioes da Saude",
					"owner_country": "Brazil"
				}
			}
		],
		"message_attributes": {
			"title": "Atenção",
			"warning_message": "Baseado nos seus sintomas, você se enquadra na definição de caso suspeito de síndrome gripal. É recomendado que você procure atendimento em um serviço de urgência mais próximo. Caso não tenha condições de se deslocar, ligue para o SAMU no número 192. Ao se dirigir a um serviço de urgência, certifique-se de tomar medidas de proteção individual e etiqueta respiratória para si mesmo(a) e para eventuais acompanhantes. Note que isto não é um diagnóstico formal. Este aplicativo não substitui um exame laboratorial e apenas fornece recomendações com base nos seus sintomas.\n\n Fonte: Ministério da Saúde",
			"go_to_hospital_message": ""
		}
	}
}'

2 - Acesse o console do rails e veja os sintomas anexados nas sindromes nas quais o sintoma já tinha sido criado, o atributo code está repetido

Comportamento Esperado

O code deve ser apenas um.

Screenshots

Descrição

É necessário adicionar uma margem da porcentagem para o retorno das síndromes. Por exemplo: apenas retornar sindromes com porcentagem maior ou igual a 20%, para que não aconteça de retornar síndromes com porcentagens muito baixas. Imagino que essa porcentagem deve ser obtida com a equipe da saúde.

Descrição

Para melhorar a nossa cobertura de testes vamos testar gradualmente o código já escrito na aplicação a começar pelas Models.
Devem ser testadas todas as models assim como seus relacionamentos e métodos

• Critérios de aceite
• Model de Admin;
• Model de App;
• Model de Content;
• Model de Group;
• Model de Household;
• Model de Manager;
• Model de School Unit;
• Model de Survey;
• Model de Symptom;
• Model de User;
• Model TwitterAPI
• Model ManagerGroupPermission

Descrição (Como usuário, eu quero quero poder cadastrar meu estado e cidade para eu possa gerar mais insights

Critérios de aceite

• Atributo state e city em Users;

Descrição

Como ADMINISTRADOR de um instituição (empresa, escola, faculdade), quero adicionar minha instituição no sistema de forma que usários possam acessar.

Esta issue é grande e consiste de diversas etapas. Deve-se criar um modelo na API chamado 'Group', que se referencia de forma recursiva de forma a gerar um árvore. Quando um administrador cadastrar sua intituição, ele terá o poder de definir como ele espera que a instituição seja estruturada. Por exemplo, a administração da UnB pode adicionar um grupo de 'campus' e, para cada grupo, 'cursos', isso por uma tabel de excel que será servida à partir do painel de administradores no guardioes web.

Decisões quanto a arquitetura foram tomadas por @gabrieldouurado @RenatoBrittoAraujo @tsrrodrigues @ViniciusPuerto.

ARQUITETURA:

MODELO DE EXCEL (exemplo):

Critérios de aceite

• Endpoint para criação de novos grupos à partir de um tabela como a representada acima, em arquivo excel.
• Endpoint para edição e remoção de linhas da tabela a partir de sistema no guardioes web.
• Exportação de dados de usário para elasticsearch formatados em string (ex: 'Brasil/DF/Asa Norte/UnB/Darcy/Software').
• Endpoint para a criação de grupo, em relação ao seu grupo pai.
• Endpoint para a remoção de grupo, incluindo seus filhos.
• Endpoint para a edição de grupo.
• Endpoint que retorna para um ID de grupo, se este grupo existe, se esse grupo é filho e senão retorna seus filhos.
• Endpoint que retorna para um ID de group, todo o caminho até chegar no grupo do usuário (ex: [{"Pais":"Brasil"},{"UF":"DF"},{"Municipio":"Asa Norte"},{"Grupo":"UnB"},{"Campus":"Darcy"},{"Curso":"Software"}]).
• Apenas managers podem adicionar, remover ou alterar grupos.
• Um manager possui um espaço onde pode adicionar ou remover grupos sem poder alterar nada externo à isso, exemplo: Brasil/DF/* para SES-DF ou Brasil/DF/Asa Norte e Brasil/DF/Gama para UnB.
• Um manager pode adicionar ou remover permissões de grupos para outros managers, desde que este esteja permitido a alterar certo grupo.
• Adaptar usuário para novo modelo de grupos.

Descrição

À pedido do Mauro Sanchez e Jonas Brandt, adicionar nas síndromes ponderações de peso para diferentes sintomas de determinada síndrome no valor de predição positiva.

Esses pessoas serão determinados em produção pelo pessoal da saúde.

A nova formula será essa:

Caso esse valor não seja informado, se assume que é 1.

Critérios de aceitação

• API aceitar a adição e modificação de parâmetros de ponderamento da relação sintoma - síndrome.

Descrição

Para deixar a aplicação mais simples de rodar e diminuir potêncial de bugs, cortar dependencias que não estão sendo utilizadas.

Descrição

Descrição do que se trata a issue.

• testar o travis

• definir stages (etapas) do pipeline de integração continua

Descrição:

Criar uma rota para fazermos o pŕe cadastro de instituições onde o usuário mande os atributos necessários para ser solicitado um cadastro

Tarefas:

• Criar um endpoint para receber esses dados
• Mandar um email para o responsável pela análise
• Definir rotina pós analise

Descrição

Adicionar o campo "Grupo de risco" ao household para que seja possível editar ou registrar com esse atributo.

Critérios de aceitação

• É possível registrar/editar um household com esse atributo

Description

When a user reports twice in one day they can't report for a holsehold, because the limit applys to the user and the holsehold combined.

Step by step

Step by step to reproduce the bug:

1. Make a good report with a user, let's call user 1.
2. Change the user to a user 2
3. Make a good report with the user 2
4. See that the report will not be pushed because the user already contributed that day

Expect behavior

The user has to be able to report 2 times a day per user/household

Descrição

Implementar sistema de upload de dados sobre sindromes e sintomas.

Tarefas

• Import de arquivo .xls por admin com o seguinte formato:

Critérios de aceitação

• O arquivo deve ser importado e seus respectivos dados devem ser registrados na base de dados.
• Validações de permissão e fornecimento de template para equipe de saúde.

Descrição

É necessário criar o CRUD para managers para que se possa usar no painel de gerenciamento no web.

Descrição

A configuração do docker dos serviços web e db estão quebrados.

Passo a Passo

Passo a passo para se reproduzir o bug:

1. Limpe as imagens docker e volumes. Limpe qualquer arquivo de cache que possa existir no sistema, como não consegui iniciar a API completamente esse tipo de arquivo pode existir.

# limpando as imagens

sudo rm -rf ./tmp/
sudo docker stop $(sudo docker ps -q)
sudo docker rmi $(sudo docker images -q) -f 

2. Siga os comandos de build no readme

sudo docker-compose build
sudo docker-compose up -d 

Comportamento Esperado

API do serviço web e database do serviço db iniciarem. Estou utilizando a branch master do projeto em questão.

Screenshots

compose_log.txt

Exemplo de compontamento após a execução do comando "docker-compose up"

Informações do Desktop:

• OS: Archlinux
• Versão do OS: 5 .5.13-arch1-1
• Browser: Firefox
• Versão do Browser: 74

Descrição (Como usuário, eu quero poder cadastrar algo que me identifique como pertencente a algum grupo para algum tipo de gamificação possa ser garantida?)

Critérios de aceite

• Novo atributo identification_code:string em Users;

Melhorar o agrupamento dos Clusters de modo que sejam apresentados de tamanhos diferentes de acordo com o numero de relatos que ele agreda.

Critério de Aceitação:

• Clusters com um numero maior de relatos agregados

Acrescentar dentro do aplicativo uma aba em que seja possível encontrar o email para contatar o suporte.

Esse email precisar ser de acordo com a instituição.

Descrição

A rota de sintomas apenas aceita um token provido de um usuário regular. Caso o token seja de um admin/manager a rota retorna um erro de status 500. É necessário que esses usuários também acessem essas rotas para que o painel de gerenciamento no web se comporte corretamente.

Passo a Passo

1. Faça login como admin e pegue o token provido na resposta
2. Faça um GET em /symptoms utilizando o token obtido no passo anterior
3. Veja o erro

Exportar os dados com filtros de instituição. (arquivo .xls on .csv)

Critérios de aceitação

• Exportação de dados somente da instituição, primeiro os usuários da instituição e depois suas surveys.

Tarefas

• Estudar uma estrategia para que no futuro a escolha das intituçoes seja escalavel

Critérios

• Documentar na issue a estratégia e suas justificativas

Adicionar o @(twitter) que será utilizado com fonte de notícias dentro do aplicativo

• Critérios de Aceitação
  [ ] Model com o campo.

Criar o Manager na API.

Criar sistemas de permissões para usuários elevados da API.

Critérios de Aceitação

• Admin tem acesso a todos os endpoints exceto os de app.
• Manager tem acesso apenas a endpoints especificos [A SE DISCUTIR]
• Manager autorizado por admin tem permissões à mais endpoints

Tarefas

• Revisar localizaçoes erradas ( plano piloto )

• Atribuir ao report a cidade certa

Criiitérios

• Report com suas respectivas cidades

Realizar a filtragem das visualizações de acordo com a instituição.

Critérios de Aceitação:

• Wireframe com as informações da instituição

Descrição

O modelo de documento de instituição escolar deve ser uma planilha .xls que deve seguir padrões para que o cadastro seja feito de forma automática, logo devemos disponibilizar um template para que sejam cadastrados seus departamentos.

Tarefas

• Criar um teplate de documento;
• Fazer o upload do documento num serviço de cloud;
• Disponibilizar o link para dowload;

**Descrição

Fazer com que só apareça na lista de instituições aquelas que pertenceram a UF selecionada pelo usuário, categoria e nivel no momento do cadastro.

Filtros

• UF
• Categoria ( Unb, IFB, SED )
• Nivel de escolaridade (SED)
• Unidades ( Unb, IFB )
• RA

Critérios de aceite

• Renderizar JSON somente a lista de instituições filtradas;

Atualizar as sintomas para contemplar todos sintomas da COVID

Tarefa

• Cadastrar todos os sintomas da COVID

Criterio de aceitação

• Esses sintomas são mostrados no aplicativo

Descrição

Verificar se todas as informações trazidas pelas requisições estão de sendo fato usadas no aplicativo. Retirar as informações que não estão sendo usadas.

Dessa maneira será possível reduzir o tamanho da reposta resultando em um ganho de performance na API e Aplicativo.

Critérios de aceite

• Verificar todos os Serializer existentes na API;
• Remover apenas informações que não estão em uso;

Descrição

Adicionar o campo school_unit_id a model de household e seus relacionamentos.

Critérios de aceite

• Campo school_unit_id na model;

Descrição

Verificar os atributos das instituições da API para ver se englobam todos os campos do pré-cadastro.
Também é necessário adicionar o campo do canal de comunicação da instituição, que provavelmente será um twitter. Será bom verificar com o @gsmartins96 qual a melhor forma de adicionar esse campo. Ex.: uma string com o user do twitter da instituição ou de outra forma.

Critério de aceitação:

• Campos estão de acordo com os campos do pré-cadastro
• Campo do canal da instituição foi adicionado

Descrição

Método delete de syndromes e symptoms não estpa funcionando.

Erro

"status": 500,
"error": "Internal Server Error",
"exception": "#<ActiveRecord::InvalidForeignKey: PG::ForeignKeyViolation: ERROR: update or delete on table "symptoms" violates foreign key constraint "fk_rails_68e0a23081" on table "syndrome_symptom_percentages"\nDETAIL: Key (id)=(12) is still referenced from table "syndrome_symptom_percentages".\n: DELETE FROM "symptoms" WHERE "symptoms"."id" = $1>",

Passo a Passo

Passo a passo para se reproduzir o bug:

1. Crie uma sindrome e um sintoma linkados um com o outro
2. Tente deletar algum
3. Veja o erro

Comportamento Esperado

Possível deletar a síndrome ou o sintoma

Tarefas

• Criar model para sindromes

• Linkar sintomas para caracterizar a sindrome

• Index de sindromes

Critérios

• Sindromes sendo criadas com seus devidos sintomas

Testar rotas para criar, excluir e editar dados da API a partir de managers e admins.

Critérios de aceitação:

• Mapear na issue para cada rota QUEM deve ter permissão para usa-las
• CRUD para gerentes - admin
• CRUD para apps - apenas proepi admin god
• CRUD para sintomas - gerente autorizado
• CRUD para sindromes - gerente autorizado
• CRUD para conteúdos - admin
• CRUD para usuários - gerente autorizado

Descrição

Ao realizar um report com sintomas, está retornando no objeto top_3(síndromes) síndromes que não estão relacionadas a nenhum dos sintomas reportados. Por exemplo, como está apenas criado no servidor a Sindrome Gripal. Ao realizar um report com o sintoma "Dor de Cabeça", que não está dentre os sintomas dessa síndrome, é retornado dentro das top_3 a Síndrome Gripal.

Passo a Passo

Passo a passo para se reproduzir o bug:

1. Faça um report com um sintoma que não está relacionado à Síndrome Gripal
2. Receba como resposta no objeto message.top_3 a Síndrome Gripal

Comportamento Esperado

Retornar apenas síndromes em que os sintomas batam com os sintomas reportados.

Descrição

Ao enviar uma requisição de PATCH para a /users/{userID} retorna status 404.

Passo a Passo

Passo a passo para se reproduzir o bug:

1. Enviar uma requisição PATCH para /users/{userID}.
2. O usuário não é editado e a requisição retorna status 404.

Comportamento Esperado

As informações do usuário devem ser alteradas e a requisição deve retornar status 200.

*Descrição

Criar uma forma de notificar a ProEpi sobre novos pré cadastros de instituição para que ela possa validar.

Tarefas

• Mandar um email com as informções do pré cadastro para validação pela proepi

Critérios

• Email sendo enviado com as devidas informações

Descrição

Devido à iniciativa de termos mais insituições de ensino e grupos participando do App entrou-se em contato com o IFB para inserirmos eles na nossa base

Tarefas

• Pegar dados necessários para o cadastro do IFB
• Receber a planilha preenchida com os sub grupos
• Fazer upload da planilha na API

Critérios

• IFB e seus sub-grupos cadastrados

Descrição:
Como usuário, eu quero poder selecionar grupos já pré definidos, durante o cadastro. para que eu possa reportar participando desses grupos

Critérios de aceite

• Model Group;
• Relacionamento com a model User de has_many e User belongs_to ;
• CRUD de Groups permitido apenas para Admin e Manager referêntes ao seu App