[docs] - update melhorias e defeitos

Signed-off-by: saracampss <[email protected]>

docs/gestao/melhorias-defeitos.md

@@ -28,14 +28,18 @@ Nas semanas finais (Release N), quando o foco era na entrega de melhorias e corr
 
 Por fim, o projeto é finalizado com a necessidade das seguintes correções de defeitos:
 
-| US | Defeito | Descrição | Prioridade |
-| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
-| US04 | Inicialmente, havia sido levantado que as telas de cadastro de usuários teriam os dados pedidos pelos P.Os. No entanto, enquanto era desenvolvida, notou-se que essa US precisava de telas para representar usuários do tipo filiados. Essa correção, no entanto, não foi finalizada a nível de interface. | A correção foi feita apenas a nível de banco de dados, já que agora as tabelas Usuário e Filiado possuem relação de herança, mas é preciso criar protótipos de como essas telas irão funcionar com a mudança e refletir isso no frontend. | A prioridade dessa correção é considerada alta, pois afeta a performance de outras US e é uma funcionalidade básica do sistema. |
-| US34 | Quando uma solicitação é rejeitada, um email deve ser enviado ao solicitante para que ele seja informado sobre a rejeição e, caso queira, entre em contato com o sindicato | Esse defeito deve ser corrigido com uma revisão simples do código, visto que, a funcionalidade foi implementada e já havia sido testada antes, mas no momento do teste de aceitação final do usuário acabou não funcionando perfeitamente | A prioridade dessa correção não é tão alta por não afetar outras US, mas por ser uma correção rápida pode ser significativamente priorizada. |
+| US | Defeito | Descrição | Prioridade |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| US04 | Inicialmente, havia sido levantado que as telas de cadastro de usuários teriam os dados pedidos pelos P.Os. No entanto, enquanto era desenvolvida, notou-se que essa US precisava de telas para representar usuários do tipo filiados. Essa correção, no entanto, não foi finalizada a nível de interface. | A correção foi feita apenas a nível de banco de dados, já que agora as tabelas Usuário e Filiado possuem relação de herança, mas é preciso criar protótipos de como essas telas irão funcionar com a mudança e refletir isso no frontend. | A prioridade dessa correção é considerada alta, pois afeta a performance de outras US e é uma funcionalidade básica do sistema. |
+| US34 | Quando uma solicitação é rejeitada, um email deve ser enviado ao solicitante para que ele seja informado sobre a rejeição e, caso queira, entre em contato com o sindicato | Esse defeito deve ser corrigido com uma revisão simples do código, visto que, a funcionalidade foi implementada e já havia sido testada antes, mas no momento do teste de aceitação final do usuário acabou não funcionando perfeitamente | A prioridade dessa correção não é tão alta por não afetar outras US, mas por ser uma correção rápida pode ser significativamente priorizada. |
+| US20 | Campo de data com formato MM/DD/YYYY | Cadastros antigos feitos antes de uma correção em relação a data ainda exibem formato MM/DD/YY, ao contrário de DD/MM/YYYY, como era esperado, apesar deste problema não ser mais gerável pelos cadastros do usuário | Baixa prioridade, não afeta outras US |
+| US20 | Campo de Conta Origem/Destino não recebe contas bancárias cadastradas | Quando selecionada a opção de Conta do Sindicato, as contas bancárias que aparecem como opção de preenchimento são estáticas | Prioridade alta, porém de baixa complexidade, já que basta uma correção, implementando a requisição GET de Contas Bancárias registradas no sistema |
+| US21 | Desfazer selção de filtro | É possível limpar todos os filtros, no entanto, o P.O fez a sugestão de implementar a limpar um filtro por vez | Prioridade a ser avaliada pelo P.O |
 
 ## Histórico de versão
 
 | Alteração | Data | Autor |
 | --------------------------------------------------------------------- | -------- | ----------- |
 | Criação do documento | 08/09/24 | Sara Campos |
 | Atualização a partir do feedback do P.O (Adiciona tabela de Defeitos) | 09/09/24 | Sara Campos |
+| Atualização a partir do feedback do P.O (Adiciona tabela de Defeitos) | 14/09/24 | Sara Campos |