## Bloqueios Prioritários - Modal de bloqueios de voz
## seguir documentação para desenvolvimento - qualquer sugestão de mudanção de task será bem vinda no A&D
[1][usage][front] - Desenvolver componente novo de check qual ficará a mercê das seleções:
=
- não dependente
- componente deverá ser desenvolvido com boas práticas de desenvolvimento web, pois o mesmo será compartilhado no storybook:
- utilização de padrão BEM para o SCSS/SASS; https://desenvolvimentoparaweb.com/css/bem/
- Evitar código css desnecessário para melhor desempenho;
- utilizar variáveis para cores que existem no design-system da Vivo;
- O componente deve seguir o mesmo padrão de funcionamento no qual apresenta já o Checkbox existente na biblioteca compartilhada, fazendo um emit para o componente pai da escolha feita pelo cliente;
- Revisar o funcionamento
- Subir o componente para o storybook, lembrando que o mesmo será de uso de todos os devs;
- testes unitários;
- testes de mutações para ver a qualidade, rodar enquanto estiver em desenvolvimento no usage local
- subir no vue-components e no storybook
- atualizar o usage quando os mesmos estiverem sendo importados - script: update-vs
Estimativa: 4
[2][usage][front] - Desenvolver componente que apresenta a escolha de selecionar todos os bloqueios:
=
- não dependente
- - utilização de padrão BEM para o SCSS/SASS; https://desenvolvimentoparaweb.com/css/bem/
- Desenvolver apenas o componente em si, pois no momento ele não irá apresentar funcionamento;
- organizar corretamente os diretórios dos arquivos que serão criados, seguindo boas práticas de organização.
Estimativa: 2
[3][usage][front] - Elaborar modal de bloqueio de voz - visual :
=
- parcialmente dependente da 1 e 2
- utilização de padrão BEM para o SCSS/SASS; https://desenvolvimentoparaweb.com/css/bem/
- Seguir os anceios presentes na documentação: https://wikicorp.telefonica.com.br/pages/viewpage.action?pageId=309494822&preview=/309494822/316344370/Captura%20de%20tela%202022-12-26%20203302.png
- Componente de Tabs está em @components/shared;
- Criar um componente base do slider que será integrado com o Slider management;
- setar caso de loading e de erro no componente;
- Dentro do componente base, setar no componente Tabs, os outros componentes, que futuramente serão do slider de voz/dados;
- Seguir de exemplo o slider que apresenta os bloqueios quando clicado no tooltip em mobile para organização de arquivos, um arquivo para o slider de voz, outro arquivo para slider de dados;
- Seguir boas práticas de nomenclaturas de arquivos e posição no diretório;
- integrar o componente com o vuex manipulador do slider management:
- criar enums para o slider;
- criar em lines/config/constants um valor novo, exemplo: "sliderBlocklistLineStepsContentDefinition: {}" contendo o id, title e type do modal... se atentar com a nomenclatura, ela é obrigada a conter as strings "LineStepsContentDefinition" no titulo.
- preparar em LineSliderManagement.vue a orquestração desses valores setados.
- Depois dos passos acima, chamar o slider nos botões individuais e o massivo.
- Utilizar já o management de linhas que possuimos em vuex pra setar a contagem do mesmo.
Estimativa: 4
[4][usage][front] - Criar os tooltips da modal de bloqueios de voz
=
- dependente da 3
- criar um mixin com computeds contendo os textos dos tooltips em 'client/src/main/components/line/management/shared/mixins', exemplo de título: LineBlockageMixins;
- fazer os testes unitários do arquivo criado no mesmo path porém em spec;
- rodar de mutações para ver a qualidade;
Estimativa: 2
[5][usage][front] - Desenvolver o fluxo de bff no qual será acordado nessa estória
=
- não dependente do front e parcialmente dependente do contrato com o back para o desenvolvimento
- dispensa explicações, é um fluxo bem conhecido dos devs;
- boas práticas em nomenclaturas e testes unitários descentes;
- rodar mutações pra ver a qualidade dos testes unitários criados;
Estimativa: 3
[6][usage][front] - Aplicar/Desenvolver fluxo de usecases e gateway que serão tratados nessa estória
=
- parcialmente dependente da 5
- já temos usecase do blocklist, é só integrar as novas chamadas;
- de resto, é um fluxo fácil e conhecido dos devs;
- testes unitários e mutações para ver a qualidade;
Estimativa: 3
[7][usage][front] - vuex da estoria
=
- parcialmente dependente da 6
- para o post do contrato:
- no vuex lines/blocklist:
- criar um store que armazene todas as linhas com todos os bloqueios pra um get;
- alterar o store da linha unica existente;
- mutation para o store acima;
- store para o objeto que será enviado com as linhas selecionadas;
- uma mutation para o item acima que entegre cada tipo de bloqueio em objetos separados no array do que será operado (ver na documentação);
- o item acima pode mudar, aguardando resposta do pessoal do NGIN
- criar action para o post ao usecase com o objeto criado;
- para o get e acrescentar no slider de bloqueio massivo:
- já possui fluxo vuex completo para get individual, utlizar o mesmo que existe em lines/blocklist para operar na edição de bloqueio individual e setar o que já vem bloqueado ou não.
- na edição de bloqueios massiva, por padrão o slider carrega com um valor definido indiferente do que já está setado nas linhas;
[-][usage][front] adequar o slider do tooltip com o novo store
=
- dependente da 7;
- o modal pode vir a quebrar, então será necessário adequar com o store selecionando os valores de bloqueio por um filter com a linha desejada pra aparecer no slider;
- testes unitários;
- testes de mutações;
Estivmativa: 5
[8][usage][front] - atribuir os metodos necessários no modal de edição de bloqueios
=
- completamente dependente de todas as tasks anteriores
- atribuir os stepers de sucesso ou erro genérico no submit, seguir exemplo de todos os sliders já feitos;
- atribuir a action criada no mesmo que já vem retornado status de erro ou sucesso;
- fazer testes unitários para TODOS os metodos, computeds e etc que serão aplicados no componente, cobrir todas as chamadas;
- rodar mutações para ver qualidade e cobertura;
## OBSERVAÇÃO: É PARA RODAR TESTES DE MUTAÇÕES NO DESENVOLVIMENTOS DOS COMPONENTES VUE. NESSE TESTE, PODEMOS TER A AFIRMAÇÃO DA QUALIDADE DOS TESTES UNITÁRIOS. É NECESSÁRIO COBRIR TODOS OS METODOS, COMPUTEDS, HOOKS, IMPORTAÇÕES E ETC... TUDO. QUANDO É ACUSADO 100% MESMO NÃO TENDO TESTES PARA OS METODOS, É PORQUE O ARQUIVO É IMPORTADO EM OUTRO E ACONTECE A COBERTURA.
## OBSERVAÇÃO 2: TESTES UNITÁRIOS SEM 'expected()', NÃO É TESTE
Estimativa: 4
[9][usge][backend] - Elaborar o serviço de bloqueios no backend que deverá servir tanto para o bloqueio individual como massivo
=
Descrição: o serviço a ser chamado pelo front deverá seguir o seguinte padrão: https://wikicorp.telefonica.com.br/pages/viewpage.action?pageId=309494822&preview=/309494822/316344370/Captura%20de%20tela%202022-12-26%20203302.png
1 - Criar um novo command
2 - escrever a assinatura do método em UsageGateway.java
3 - Elaborar os tratamentos de chamada prevenindo contra erros
4 - elaborar testes unitários;
5 - rodar testes de mutação e eliminar possíveis mutantes;
Estimativa: 3
[11][backend] - Fazer as tratativas do callback vindo NGIN
DESCRICAO: DETALHAR O QUE DEVE ser feito
Estimativa: 3
[12][backend] - definir os status das linhas com operacao de bloqueios
Estimativa: 1
[13][front] - definir os status de bloqueios alinhado com o time de front;
Estimativa: 2
[14][tagueamento] - Criar os tagueamentos da modal de bloqueios prioritários
descricao: criar os tagueamentos conforme descrito no Whimscal
Estimativa: 2
[https://wikicorp.telefonica.com.br/pages/viewpage.action?pageId=309494822](https://)
[11][tagueamento] - validar os tagueamentos com o time da gauge
descrição: enviar um e-mail para o time da gauge sinalizando uma reunião a ocorrer em data de comum acordo
Estimativa: 1
[12][qa] - liberar a história para o time de QA
descrição: fazer o deploy dos módulos usage front e usage back end em pre
Estimativa: 1
[13][testes] - Elaborar os testes exploratórios
descrição: fazer testes exploratórios da história e elaborar documento de evidências
Estimativa: 4
[14][front] - realizar testes de componentes
descrição: realizar os testes de componentes de acordo com o caderno de testes, incluindo os tagueamentos que serão desenvolvidos
Estimativa: 5
[15][kt] - elaborar o documento do KT
desrição: elaborar o documento do kt e apresentar na reunião que antecede a CRQ (MATHEUS MONTENEGRO)
Estimativa: 1
[16][UX-UI] - Validar telas desenvolvidas com a equipe de UX/UI
descrição> marcar uma reunião com o pessoal de UX/UI, fazer a apresentação da modal desenvolvida e anotar as possíveis inconsistências; Incluir do ambiente para o pessoal fazer a validação
Estimativa: 1
[16][UX-UI] - teste de regressao
descrição> marcar uma reunião com o pessoal de UX/UI, fazer a apresentação da modal desenvolvida e anotar as possíveis inconsistências; Incluir do ambiente para o pessoal fazer a validação
Estimativa: 2