O GLPI 12 ainda está em desenvolvimento, mas já é possível acompanhar algumas das mudanças que estão sendo trabalhadas no repositório oficial.
Não estamos falando apenas de uma nova interface ou de alterações visuais. O projeto está passando por uma modernização importante em sua estrutura, principalmente no frontend, na organização dos componentes e na redução de dependências antigas.
Como ainda não existe uma versão estável, tudo que apresentamos neste conteúdo deve ser tratado como uma análise do estado atual do desenvolvimento. Funcionalidades, requisitos e até mesmo decisões técnicas ainda podem mudar.
Modernização da interface
Uma das principais mudanças em andamento está no frontend do GLPI.
Hoje, o sistema ainda possui componentes construídos em diferentes momentos do projeto. Algumas áreas utilizam páginas PHP tradicionais, outras já usam Twig, JavaScript moderno e Vue.js.
No GLPI 12, a tendência é ampliar essa modernização e padronizar mais a interface.
Entre os trabalhos que já conseguimos observar estão:
maior utilização de Vue.js;
substituição gradual de componentes antigos;
redução da dependência de jQuery;
modernização dos seletores;
revisão dos componentes de upload;
padronização de campos e formulários;
melhorias na navegação;
migração do processo de compilação para o Vite.
O Vite deve facilitar o desenvolvimento e a manutenção dos componentes do frontend. Para o usuário final, porém, o principal ganho deve ser uma interface mais consistente e com comportamentos mais padronizados.
Ainda assim, essa migração está em desenvolvimento e não deve ser considerada concluída até a publicação da versão estável.
Uma interface mais padronizada
Quem administra o GLPI há algum tempo sabe que alguns módulos possuem comportamentos diferentes entre si.
Isso acontece porque partes da interface foram criadas em épocas diferentes e utilizando tecnologias diferentes.
O GLPI 12 deve reduzir esse problema por meio da reutilização de componentes.
Isso pode trazer melhorias em áreas como:
seleção de entidades;
árvores hierárquicas;
campos de formulários;
anexos;
menus;
filtros;
mensagens de validação;
caixas de seleção;
editores;
pesquisas.
Na prática, o sistema tende a ficar mais previsível para quem utiliza e mais simples de manter para quem desenvolve plugins ou integrações.
Base de Conhecimento
A Base de Conhecimento também está passando por alterações.
O trabalho envolve o editor de conteúdo, o gerenciamento de arquivos, a navegação entre artigos e a organização das informações.
Essa é uma área importante para empresas que utilizam o GLPI não apenas para chamados, mas também como:
base de procedimentos;
portal interno de documentação;
central de autoatendimento;
repositório de soluções;
apoio para equipes de atendimento.
Como o recurso ainda está sendo testado, existem ajustes pendentes relacionados à interface, traduções, desempenho e comportamento de categorias.
Portanto, ainda não é possível afirmar exatamente como a Base de Conhecimento será entregue na versão final.
Ativos personalizados
Os ativos personalizados foram uma das principais novidades do GLPI 11.
Esse recurso permite criar novos tipos de ativos sem precisar alterar diretamente o código-fonte do GLPI.
Uma empresa pode utilizar essa funcionalidade para controlar, por exemplo:
máquinas industriais;
equipamentos médicos;
veículos;
mobiliário;
ferramentas;
equipamentos de laboratório;
qualquer outro objeto específico da operação.
No GLPI 12, a expectativa é que esses ativos fiquem cada vez mais integrados ao restante da plataforma.
Entre os pontos que precisam continuar evoluindo estão:
pesquisas;
permissões;
relacionamentos;
entidades;
históricos;
formulários;
regras;
API;
importações.
Essa evolução é importante porque permite utilizar o GLPI além do inventário tradicional de computadores, monitores, impressoras e equipamentos de rede.
Modernização interna
Nem todas as mudanças serão visíveis na tela.
Uma parte importante do trabalho do GLPI 12 está acontecendo na estrutura interna do sistema.
Entre os pontos observados estão:
refatoração do código PHP;
redução de código legado;
maior utilização de templates Twig;
criação de componentes reutilizáveis;
substituição de bibliotecas antigas;
melhorias nos testes automatizados;
revisão do frontend;
melhorias no sistema de traduções;
evolução das APIs;
compatibilidade com versões mais recentes do PHP;
revisão da compatibilidade com os bancos suportados.
Esse tipo de mudança não costuma chamar tanta atenção quanto uma nova tela, mas é essencial para manter o projeto sustentável.
Quanto menor a dependência de código antigo, mais fácil fica corrigir problemas, implementar novas funcionalidades e manter plugins compatíveis.
A documentação técnica atual do GLPI já mostra essa transição para uma arquitetura mais modular, baseada em controladores, templates, APIs e componentes modernos.
APIs e integrações
Outro ponto que precisa ser acompanhado com atenção é a evolução das APIs.
Hoje, muitos ambientes utilizam o GLPI integrado com:
sistemas de RH;
ERPs;
ferramentas de monitoramento;
soluções de BI;
Active Directory e LDAP;
plataformas de automação;
n8n;
sistemas próprios;
portais externos;
soluções de inventário.
Uma mudança de versão principal pode alterar endpoints, permissões, campos ou formatos de retorno.
Por isso, quem possui integrações críticas precisa testar principalmente:
autenticação;
criação e atualização de chamados;
leitura de ativos;
pesquisas;
envio de documentos;
relacionamentos entre objetos;
permissões dos usuários de API;
retorno dos endpoints.
Não é seguro considerar que uma integração que funciona no GLPI 11 continuará funcionando da mesma maneira no GLPI 12 sem validação.
Segurança
A segurança continua sendo trabalhada dentro do projeto.
Já existem discussões e implementações relacionadas a controles adicionais para operações sensíveis, revisão de permissões e reautenticação em determinadas ações.
Mesmo assim, é importante não esperar o GLPI 12 para manter o ambiente seguro.
As correções de segurança continuam sendo publicadas nas versões de manutenção do GLPI 11. Portanto, os ambientes de produção devem permanecer atualizados.
Também continuam valendo as recomendações básicas:
não alterar o core;
manter plugins atualizados;
remover plugins abandonados;
revisar permissões;
proteger arquivos de configuração;
utilizar HTTPS;
manter PHP e banco atualizados;
executar as ações automáticas corretamente;
revisar usuários de API;
manter backup do banco e dos arquivos.
Compatibilidade dos plugins
Esse provavelmente será um dos principais pontos de atenção na migração.
Uma nova versão principal pode alterar classes, métodos, hooks, componentes JavaScript, templates e estruturas utilizadas pelos plugins.
Antes de atualizar, será necessário validar:
se o plugin possui versão compatível;
se o projeto continua sendo mantido;
quais versões do PHP são suportadas;
se existem alterações no banco;
se houve mudança nos hooks;
se o frontend do plugin continua funcionando;
se as permissões continuam corretas;
se as ações automáticas funcionam;
se existe processo oficial de migração.
Plugins abandonados ou que alteram diretamente o comportamento do core representam um risco maior.
Quem possui muitos plugins instalados deve começar os testes antes do lançamento da versão estável.
Customizações no core
Se o ambiente possui alterações diretamente nos arquivos do GLPI, a atualização será mais complicada.
Essas alterações podem ser sobrescritas durante o upgrade ou simplesmente deixar de funcionar.
O ideal é que as customizações sejam feitas utilizando:
plugins;
APIs;
webhooks;
integrações externas;
recursos oficiais de personalização.
Antes de testar o GLPI 12, é importante levantar todas as alterações existentes no ambiente.
Isso inclui:
arquivos PHP modificados;
templates alterados;
CSS personalizado;
JavaScript personalizado;
mudanças manuais no banco;
triggers;
views;
integrações;
plugins próprios.
Sem esse levantamento, fica difícil separar um problema do GLPI de um problema causado por uma customização antiga.
O GLPI 12 já pode ser utilizado em produção?
Não.
A versão atual deve ser utilizada apenas em laboratório.
Ela pode ser usada para:
conhecer a nova interface;
testar plugins;
validar integrações;
analisar mudanças técnicas;
verificar possíveis incompatibilidades;
testar fluxos de atendimento;
preparar a equipe para a migração.
Por ainda estar em desenvolvimento, podem ocorrer:
erros;
regressões;
alterações no banco;
funcionalidades incompletas;
mudanças na interface;
incompatibilidade com plugins;
problemas de tradução;
mudanças sem aviso prévio.
Também não recomendamos conectar uma versão de desenvolvimento diretamente ao banco de produção.
O teste deve ser feito com uma cópia isolada do banco e dos arquivos.
Estamos acompanhando e testando o GLPI 12
Na Nextools e na JMBA Soluções, já estamos acompanhando o desenvolvimento do GLPI 12 e executando testes com as versões disponíveis.
Nosso objetivo é identificar antecipadamente impactos em:
plugins;
integrações;
banco de dados;
infraestrutura;
autenticação;
APIs;
customizações;
processo de atualização.
Para facilitar esses testes, disponibilizamos uma imagem Docker com a versão de desenvolvimento do GLPI 12.
Para baixar:
docker pull jmbasolucoes/glpi:12-dev
A imagem é destinada exclusivamente a testes.
Ela não deve ser utilizada em produção.
Com ela, é possível subir rapidamente um ambiente para:
avaliar a interface;
testar plugins;
validar LDAP e SSO;
testar integrações;
analisar o inventário;
revisar formulários;
verificar regras;
identificar incompatibilidades.
Antes de testar uma atualização, utilize sempre uma cópia do ambiente.
Não conecte essa imagem ao banco de dados de produção.
Exemplo de ambiente Docker
Abaixo está um exemplo simples para subir o GLPI 12 com um banco exclusivo para laboratório:
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
Para iniciar:
docker compose up -d
Depois, acesse:
http://localhost:8080
Esse compose é apenas um exemplo de laboratório e deve ser ajustado de acordo com o ambiente.
Como se preparar para o GLPI 12
Não é necessário esperar a versão estável para começar a preparação.
O primeiro passo é organizar o ambiente atual.
Atualize o GLPI 11
Antes de pensar no GLPI 12, mantenha o GLPI 11 atualizado.
Migrar a partir de uma versão antiga aumenta a quantidade de alterações e dificulta a identificação de problemas.
Faça um inventário dos plugins
Liste todos os plugins instalados e registre:
versão;
desenvolvedor;
finalidade;
criticidade;
status de manutenção;
dependências;
compatibilidade.
Plugin instalado e não utilizado deve ser removido.
Documente as integrações
Registre:
endpoint;
método de autenticação;
usuário utilizado;
campos enviados;
campos recebidos;
frequência;
dependências;
tratamento de erros.
Crie um ambiente de homologação
O ambiente de testes deve reproduzir o máximo possível da produção:
PHP;
banco;
plugins;
configurações;
autenticação;
regras;
notificações;
cron;
integrações.
Crie um roteiro de validação
Não adianta somente abrir o GLPI e verificar se a tela carregou.
É necessário testar os principais processos:
abertura de chamados;
regras de atribuição;
SLA;
notificações;
formulários;
aprovações;
tarefas;
inventário;
LDAP;
SSO;
ações automáticas;
API;
relatórios;
dashboards;
permissões;
entidades.
O que realmente esperamos do GLPI 12
Pelo que conseguimos observar até agora, o GLPI 12 não será apenas uma troca de versão.
O projeto está preparando uma base mais moderna para os próximos anos.
Os principais pontos são:
modernização do frontend;
maior utilização de Vue.js;
redução de dependências antigas;
padronização da interface;
evolução dos ativos personalizados;
melhorias na Base de Conhecimento;
revisão das APIs;
melhorias internas de segurança;
manutenção mais simples do código;
melhor estrutura para futuras funcionalidades.
Ainda não é possível afirmar quais funcionalidades estarão na primeira versão estável.
Também não é possível garantir que tudo que aparece hoje no desenvolvimento será entregue exatamente da mesma forma.
O momento agora é de acompanhar, testar e identificar impactos.
Quem possui um ambiente simples provavelmente terá um processo de migração mais tranquilo.
Quem possui muitos plugins, integrações e alterações próprias precisa começar a validação com antecedência.
Para iniciar os testes:
docker pull jmbasolucoes/glpi:12-devNos próximos conteúdos, vamos compartilhar os testes que estamos realizando, as diferenças em relação ao GLPI 11 e os problemas encontrados durante essa preparação.
Já está testando o GLPI 12? Conte para nós o que funcionou, o que quebrou e quais mudanças você encontrou.
Aviso: este conteúdo considera o estado de desenvolvimento do GLPI 12 em julho de 2026. Por se tratar de uma versão ainda não estável, funcionalidades, requisitos, estrutura e comportamento podem mudar.
