Relatório de Bug

  • Versão do Novo SGA: v2.2.1
  • Banco de dados: MySQL 5.7
  • Sistema operacional: UBUNTU 24 Host Docker
  • Usando Docker?: Sim

URLNOVOSGA/novosga.users/3/edit

Na página de edição de usuários aparentemente o checkbox está imputando as informações na base de dados na tabela Usuarios, definindo corretamente 0 e 1 na coluna "Ativo", porém não está ficando inativo e loga normalmente no sistema. Alguém já fez esse teste? Como acho a função para correção?
Já fiz os dois testes, migrei minha base de dados existente da versão 2.1, e tive apenas duas intercorrências:
Quando o admin é migrado de outra base dependendo do que é editado ocasiona um erro de !DOCTYPE ">", mas resolvi deletando e criando o admin novamente. E estou com um problema que esta intermitente que não sei muito bem como simular dependendo como eu crio o usuario e defino seu perfil as vezes quando inativo ele, quando vou logar, apresenta o erro INTERNAL ERRO 500, que no log do sistema apresenta a seguinte mensagem: erro na linha 98 do arquivo UserProvider.php.

E só para complementar fiz uma instalação limpa via docker novamente realizei alguns cadastros e mesmo assim os usuários não ficam inativados no sistema.

Alguém tem alguma luz 🙂
Obrigado!!!


Olá, rogeriolino

Fiz o re-pull do contêiner da versão 2.2.3 e está tudo okay com relação a inativação de usuários.
Porém, agora o painel de senhas não autentica, erro ("POST /api/token HTTP/1.1" 500 68 "http://IP_PAINEL: PORTA/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36" "-" 0.002 0.002 . -). Limpei a base mas mesmo assim não foi.

Reinstalei toda maquina novamente na v2.2.3 para teste, mas não autenticou com a api.

Retornei para versão 2.2.2 e o painel autentica normalmente nesta versão.

    andersonmnz antes mesmo de gerar esse fix eu tinha refatorado o CI do projeto, separando a parte de teste da parte de geração do container.

    Para o funcionamento do OAuth2 precisa gerar um certificado, e na fase de testes há um passo para gerar esse certificado, que acabou sendo jogado para dentro da imagem na hora do build:

          - name: Generate certificate
        run: |
          mkdir config/jwt
          openssl genrsa -out config/jwt/private.pem 2048
          openssl rsa -in config/jwt/private.pem -pubout -out config/jwt/public.pem

    Você pode seguir o mesmo comando para gerar o seu certificado e mapear o volume no container:

    docker run --rm \
    -e DATABASE_URL="mysql://...." \
    -p 8080:8080 \
    -v './config/jwt:/var/www/html/config/jwt' \
    novosga/novosga:2.2.3

    Caso você gere um certificado com senha, é necessário passar a variável OAUTH_PASSPHRASE também:

    docker run --rm \
    -e DATABASE_URL="mysql://...." \
    -e OAUTH_PASSPHRASE=123456 \
    -p 8080:8080 \
    -v './config/jwt:/var/www/html/config/jwt' \
    novosga/novosga:2.2.3

    Onde ./config/jwt é o caminho, da máquina host, para o diretório onde estão os arquivo pem.

      andersonmnz de qualquer forma, como desde a versão 2.2.0 o certificado já estava sendo gerado automaticamente na imagem Docker, eu vou atualizar o Dockerfile para incluir essa geração do certificado, depois gero outro fix (2.2.4)

        Maravilha, criei o diretório e os certificados diretamente no contêiner na v2.2.3 mesmo e funcionou perfeitamente.
        Nem imaginei que poderia ser isso, como não achei nenhum log aparente no sistema e também não sei se gera.

        Muito obrigado pelos esclarecimentos, bug resolvido. 🙂

          andersonmnz só reforçando que na v2.2.4 "corrigi" essa falta do certificado. Então se subir para a v2.2.4 nem precisa mapear o diretório.

            10 dias depois