cmcuritiba/chamados

chamados's Issues

Retirar módulo de autenticação do projeto e utilizar pacote django-cmcldapauth

Utilizar Vue.js para combos interligados, atualizações, etc

Atualmente essas funcionalidades usam jquery, que apesar de funcionar, torna a manutenção muito complicada.
O objetivo é substituir o JQuery pelo Vue.js que torna mais fácil a manutenção.
Não é urgente, mas seria uma boa substituir.

Acertar layout email

Provavelmente o layout está em formato texto, mas o renderizador está usando formato HTML

Responsividade Celular

Verificar responsividade pois em teste no firefox e no chrome a lista de chamados ficou fora da tela.

Desabilitar setor "Recebe chamados"

Não exibir o setor no campo ao abrir novo chamado, quando desabilitar setor para receber chamados na tela de administração.

Conteúdo do e-mail disparado pelo sistema

Seu chamado foi atualizado e agora encontra-se desta maneira :
Status : ABERTO
Última resposta : ultima_resposta

---

Número do chamado : 13
Data de abertura : 6 de Dezembro de 2017 às 09:43
Solicitado ao setor : Divisão De Desenvolvimento De Sistemas
Serviço : Taquigrafia/Bug
Assunto : assunto do chamado

Este é um e-mail automático enviado pelo Controle de Chamados da CMC, por favor não responda.

Bootstrap - /var/run

Verificar novo formato para resolver problema de "apagar" pastas do /var/run/...

Telefonia - Pesquisa de Ramais

Descrição

Pesquisa de ramais

Requisito 1

Gerar dados no formato JSON para alimentar datatable

Requisito 2

Paginação de 20 items

Requisito 3

Filtrar por departamento e nome

Requisito 4

Opção de imprimir/PDF pesquisa

Cadastro de setores

Requisito 1 (OK)

Deverá mostrar a lista de todos os setores cadastrados na Elotech e sincronizados com o BD e o administrador irá selecionar os setores que farão parte das filas de chamados.
Campos que deverão ser gravados :

• Nome do setor (obrigatório)
• ID do setor Elotech (obrigatório)
• Recebe chamados (default = False)

Requisito 2 (OK)

A partir da gravação do(s) setor(es) no BD, já será possível criar um chamado para o(s) setor(es)

Requisito 3 (OK)

Não haverá opção para excluir ou incluir setores.

Requisito 4 (OK)

Alteração apenas possível para o campo Recebe chamados.

Requisito 5 (OK)

ID do setor Elotech deverá ser único.

Cadastro Grupo Serviço e Serviço fora admin

Descrição

Opção para cadastrar esses itens fora do admin do Django

Requisitos

Requisito 1

O usuário logado deve ter acesso apenas aos grupos e serviços do seu setor

Configuração do Redis nos servidores

Configuração REDIS/Celery socket

Mudar a configuração do Redis e Celery para usar sockets. Atualmente está usando a porta 6379.

Corrigir e adicionar funcionalidades no menu

• Colocar como "tela inicial" a lista de chamados do usuário
• Adicionar esta tela no menu

Testes LDAP Travis

Configurar testes para rodar no Travis. Provavelmente teremos que fazer mock de algumas funções devido aos testes de conexão que são feitos no ldap-desenv e que deverão ser "mockados" no travis.

Filtro na listagem de serviços

O filtro por grupos de serviços na tela de serviços não é aplicado corretamente após criar um novo serviço para um grupo.

Para reproduzir: como administrador/gerente, ao acessar Cadastro / Serviços / selecionar um grupo, clicar em Novo, criar um novo serviço e clicar em Salvar. Após a criação, a listagem aparece com todos os serviços disponíveis ao invés de listar apenas do grupo selecionado no combobox.

Configurar sockets

Ao reiniciar o servidor, os sockets criados em /var/run/webapps/{aplicacao} são deletados automaticamente pelo SO.
O /var/run é o caminho correto para utilizar os sockets mas nós devemos garantir que os sockets sejam criados toda vez que a aplicação for lançada.

Configuração Travis

Configurar projeto para integração contínua usando o Travis.

Criar o arquivo .travis.yml no raiz do projeto com as configurações de build.

Fechamento de chamado sem descrição

Solicitar resposta ao fechar chamado caso o mesmo não tenha nenhuma resposta cadastrada

Cadastro de serviços

Requisito 1

Relacionamento muitos para um, ou seja, um grupo de serviço pode ter vários serviços.

Requisito 2

Campos :

• descrição do serviço (obrigatório, máximo 300)
• grupo do serviço (relacionamento)

Ajustes finos no Celery

Melhorar a configuração do celery para executar as tarefas assíncronas.

Deploy em produção

Adicionar arquivos de configuração (nginx, supervisor, gunicorn) para produção.

Anexar arquivos

O usuário poderá fazer upload de arquivo, por exemplo, uma foto do problema.
Pensar sobre filtragem de tipos de arquivos permitidos e tamanho máximo.

Não é urgente e não é necessário para a versão 1.0.

Setor via v_setor

Descrição

Fazer o cadastro de setores que atendem chamados utilizando a view v_setor (elotech)

Requisito 1

Deverá ter chave estrangeira linkando v_setor

Requisito 2

Campo Recebe chamados obrigatório tipo booleano

Requisito 3

Usuário deverá selecionar o setor através de combo e alterar apenas o campo recebe chamados

Estrutura inicial cookiecutter

Criar a estrutura inicial do projeto baseado no template cookiecutter-django

Retirar admin sites

Não há necessidade para esta aplicação.

Novos Status

1. Criar Status para Cancelamento:
   Caso um chamado seja aberto por engano, setor errado, entre outros problemas o solicitante poderá cancelar o chamado.

2. Criar Status Pausado

- Discutir como melhor funcionará com @aleodoni

Padrão email

Descrição

Deve ser assim, usar o endereço de envio e resposta [email protected]. Mas o nome/label do remetente deve ser o do sistema em uso. Todos os sistemas devem usar o no-reply com seu nome independente, aí o usuário vai receber na caixa de entrada dele um e-mail, p.e., do "Sistema de Chamados", sabe?
Não é necessária senha para usar mas se você quiser usar é a senha de root do desenv.

Adicionar ícone aba do sistema

Para poder diferenciar das demais abas do browser

Telefonia - Relatório de Ramais Hierarquizado

Descrição

Gerar relatório de ramais baseado na hierarquia do sistema Elotech

mudar servidores staging e prod nginx

chamados
10.0.0.62 -> chamados.cmc.pr.gov.br
10.0.0.61 -> chamados.staging.cmc.pr.gov.br

Cadastro de atendentes

Requisito 1 (OK)

Login/Validação será feita através LDAP

Requisito 2 (OK)

Possibilidade de filtrar pelo setor e pesquisar pelo nome do atendente

Requisito 3 (OK - Implementar na issue #14)

Qualquer tipo de alteração na lotação do atendente deve refletir automaticamente no sistema. (relacionada com issue #14)

Requisito 4 (OK - Implementar na issue #14)

Caso haja alteração na lotação do atendente, todos os chamados abertos relacionados a ele devem ser colocados novamente na fila de chamados abertos.

Requisito 5 (OK - Campo para isso já relacionado)

Cada setor deverá ter um admin que será buscado pelo LDAP/Elotech* para receber futuras mensagens do sistema.

Requisito 6 (OK)

O LDAP deverá permitir acesso a todos os campos necessários ao cadastro.

Relacionamento entre campos LDAP/Django

• uid : username
• givenName : first_name
• sn : last_name
• mail : email
• employeeNumber : matricula
• departmentNumber : lotado (ID elotech)
• employeeType : chefia

Pendências

1. Definir com Tora qual campo do LDAP irá conter o setor em que o usuário está lotado.
Definido campo departmentNumber
2. Definir estrutura/funcionamento da sincronia de informações entre o sistema da elotech/LDAP
Criada issue #14 para contemplar essa necessidade.
3. Definir estrutura e issues para "espelho" de informações do organograma cadastrado no sistema Elotech
Criada issue #14 para contemplar essa necessidade.
4. Definir com Tora se o acesso ao LDAP para leitura das informações será anônimo ou se criaremos um usuário específico para isso. De qualquer maneira que for acessado, deve ser permitido o acesso à todas as informações necessárias.
Definido acesso anônimo. Problema de permissões na verdade era o servidor de LDAP que estava sendo acessado.
5. Sobrescrever o método de gravar dados do usuário no BD para que o campo "MEMBRO DA EQUIPE" fique como True
Não é necessário. is_staff é setado True apenas para usuários que podem acessar o admin.

Sincronia Elotech LDAP

Descrição

Fazer a sincronia dos campos LDAP utilizando as views da Elotech.
A princípio, deverão ser sincronizados com o LDAP as seguintes informações referentes aos funcionários :

1. Número de matrícula do servidor
2. Setor em que o servidor está lotado
3. Informação referente à disponibilidade do servidor. Se ele está de férias, de licença, de atestado,etc. deve ficar como indisponível. Caso contrário ficará como disponível.

Existe a view V_SETOR que foi criada especificamente para a TI da CMC, e que possui as informações referentes à lotação dos funcionários.
De acordo com o pessoal da Elotech, existem mais duas views são usadas pelo sistema e fornecem as outras informações desejadas.
Deverá ser feita análise para verificar se serão utilizadas as views (do sistema) ou se serão criadas novas views específicas para a TI da CMC.

Requisito 1

Esta rotina deverá ser executada em intervalos que deverão ser definidos pelos responsáveis.

Requisito 2

A rotina deverá acessar o LDAP para poder ler e gravar as informações necessárias.

Requisito 3

Em caso de erro, a rotina deverá avisar o responsável do acontecido.

Mudar tipo campo chefia de BooleanField para NullBooleanField

Remover chamadas servico pessoa

Deverá ser substituído por servicos "funcionario"

Filtrar corretamente Serviço/Grupo Serviço

Bug conhecido no datatables. Filtrar exatamente o codigo do grupo, não usando '%'

Relatórios

Todos deverão ser emitidos por período e exibindo todos os dados do chamado
Criar opção para selecionar por Grupo de Serviços
Criar opção para selecionar por Setor Solicitante
Criar opção para selecionar por Status

Cadastro de grupos de serviços

Requisito 1

Deverá estar relacionado com o setor

Requisito 2

Campos :

• descrição do grupo de serviço (obrigatório, máximo 300 caracteres)
• setor (relacionamento)

Limitar CRUD no cadastro de usuários

Requisito 1

Não permitir inclusão de usuário

Requisito 2

Não permitir exclusão de usuário

Requisito 3

Não permitir alteração dos dados do usuário, com exceção do campo is_staff que dá acesso ao admin

Criar campos localização e andar e filtrar por setor

Estes campos deverão estar habilitados para os setores específicos (instalações e patrimônio)

Fila de chamados

Requisito 1 (OK)

Quando o atendente se logar, deverá aparecer 2 filas de chamados :

1. Fila de chamados abertos para o setor
2. Fila de chamados selecionados pelo atendente

Requisito 2 (OK)

Fila de chamados abertos para o setor
Mostrar lista com os seguintes campos :

• ID do chamado
• Data de abertura
• Assunto
• Nome do solicitante

Requisito 2.1 (OK)

Ordenar os chamados abertos pela data de abertura (os mais antigos na frente)

Requisito 3 (OK)

Fila de chamados selecionados pelo atendente
Campos e ordenação iguais ao requisito 2, filtrando pelo atendente logado.

Requisito 4 (OK)

Possibilitar ao atendente abrir um chamado caso o usuário entre em contato direto com ele.

Requisito 5 (OK)

O setor do atendente deverá ser buscado via microserviços e o atendente automaticamente colocado na fila de chamados do mesmo.

Requisito 6 (OK)

Qualquer alteração no status ou conteúdo do chamado deverá notificar via sistema e disparar um e-mail para o usuário que abriu o mesmo.

PENDÊNCIAS

• Qualquer usuário terá acesso à fila de atendimento? Qualquer do setor. (OK)
• Qual será a tela inicial ? Tela de atendimento ou tela de chamados abertos ? se atendente é na tela de atendente, senão na tela de chamados dele. (OK)
• Reabertura de chamados fechados ? Pode acontecer ? Qualquer um ? Pode, qualquer um pode acessar e reabrir o seu chamado(atendentes + dono do chamado). (OK)
• Verificar com Bruno configurações conta e servidor de email bem como layout do email.
  [email protected] (OK)
• Somente o atendente e o chefe podem devolver o chamado (OK)
• Diretor pode ver chamados de todos os seus setores inferiores. (Fábio vai passar funções de diretoria e setores abaixo.) (OK - Já resolvi por conta)

Abertura de chamado

Requisito 1 (OK)

Para abrir um chamado, o usuário deverá estar logado no sistema via LDAP.

Requisito 2 (OK)

Usuário deve selecionar o setor que receberá o chamado através de lista (combo)

Requisito 3 (OK)

Usuário deverá selecionar o grupo de serviço. Esta lista deverá estar filtrada pelo setor escolhido anteriormente.

Requisito 4 (OK)

Usuário deverá selecionar o serviço. Esta lista deverá estar filtrada pelo grupo de serviço escolhido anteriormente.

Requisito 5 (OK)

Usuário deverá informar o ramal de contato. Verificar a possibilidade de trazer o ramal já preenchido buscando essa informação no LDAP/elotech

Requisito 6 (OK)

Usuário informa o assunto do chamado (não obrigatório)

Requisito 7 (OK)

Usuário entra com o texto contendo informações complementares do chamado (print screen, etc). Usar um editor de texto tipo tinymce

Requisito 8 (OK)

Campos que serão preenchidos automaticamente :

• Data de abertura do chamado
• Prioridade do chamado (normal)
• Status do chamado (aberto)

Requisito 9 (OK)

Após chamado ter sido gravado, as seguintes ações deverão acontecer :

• Email (definir padrão) será enviado para o usuário que abriu o chamado
• O chamado deverá aparecer na fila de chamados do setor

Requisito 10 (OK)

Caso seja troca ou defeito de equipamento, o usuário deverá informar o número de série ou o número de patrimônio do objeto.

Requisito 11 (OK)

Número de patrimônio relacionado aos itens de setor.

Telefonia - Cadastro de Ramais

Descrição

Fazer o cadastro de ramais baseado na hierarquia do sistema da Elotech.

Requisito 1

A lista de setores/departamentos/etc deverá ser buscada no sistema da Elotech (view V_SETOR)

Requisito 2

A lista de departamentos/setores/etc deverá ser mostrada através de combo, sem hierarquia.

Requisito 3

O usuário selecionará o setor e cadastrará o ramal do mesmo.

Envio assíncrono de email

Aplicação deve usar o envio assíncrono de emails para não deixá-la lenta.
Opção de usar o Celery

Nova resposta não envia email

responde_json envia_email not defined

Correção layout tela chamados usuário

• Corrigir layout
• Implementar filtro combos setor, grupo de serviço e serviço
• Caso chamado tenha alteração conteúdo/status, mostrar icone de alerta para o usuário

Adicionar Vue.js no projeto

Biblioteca https://vuejs.org/v2 no projeto.

Filtrar apenas setores ativos

Erro 500 ao fazer login

Em anexo uma print do erro e um .html da página gerada. A senha foi censurada por motivos óbvios.

HTTPError at autentica_valida-usuario.txt

Arquivo .html foi renomeado para .txt porque GitHub não gosta de htmls.

Modificar chave de identificação do funcionário

Atualmente, a chave utilizada é a matrícula do funcionário, mas esta chave não é única, ou seja, existem casos em que o mesmo número de matrícula identifica usuários diferentes (no caso estagiários).

Então devemos usar outra chave que seja única e identifique apenas um único usuário. Esta chave (a confirmar) deverá vir da tabela Pessoa.

Confirmando esta unicidade da chave, deveremos mudar todas validações, buscas, etc que hoje utilizam a matrícula para identificar o usuário para esta nova chave.

Deploy primeira versão funcional no servidor Staging

Realizar o primeiro deploy no servidor staging