O GLPI 12 ainda está em desenvolvimento, mas já é possível acompanhar algumas das alterações que estão a ser trabalhadas no repositório oficial.
Não estamos a falar apenas de uma nova interface ou de alterações visuais. O projeto está a passar por uma modernização importante na 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 o que apresentamos neste conteúdo deve ser tratado como uma análise do estado atual do desenvolvimento. As funcionalidades, os requisitos e até as decisões técnicas ainda podem mudar.
Modernização da interface
Uma das principais alterações em curso está no frontend do GLPI.
Atualmente, 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 utilizador 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é à publicação da versão estável.
Uma interface mais padronizada
Quem administra o GLPI há algum tempo sabe que alguns módulos têm comportamentos diferentes entre si.
Isso acontece porque partes da interface foram criadas em épocas diferentes e com recurso a tecnologias diferentes.
O GLPI 12 deve reduzir esse problema através 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 o utiliza e mais simples de manter para quem desenvolve plugins ou integrações.
Base de Conhecimento
A Base de Conhecimento também está a passar por alterações.
O trabalho envolve o editor de conteúdo, a gestão de ficheiros, 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 tickets, mas também como:
base de procedimentos;
portal interno de documentação;
central de autoatendimento;
repositório de soluções;
apoio para equipas de atendimento.
Como o recurso ainda está a ser testado, existem ajustes pendentes relacionados com a 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.
Este recurso permite criar novos tipos de ativos sem ser necessário alterar diretamente o código-fonte do GLPI.
Uma empresa pode utilizar esta 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 estes ativos fiquem cada vez mais integrados com o resto da plataforma.
Entre os pontos que precisam de continuar a evoluir estão:
pesquisas;
permissões;
relacionamentos;
entidades;
históricos;
formulários;
regras;
API;
importações.
Esta evolução é importante porque permite utilizar o GLPI para além do inventário tradicional de computadores, monitores, impressoras e equipamentos de rede.
Modernização interna
Nem todas as alterações serão visíveis no ecrã.
Uma parte importante do trabalho do GLPI 12 está a acontecer 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 as bases de dados suportadas.
Este tipo de alteração não costuma chamar tanta atenção como um novo ecrã, mas é essencial para manter o projeto sustentável.
Quanto menor a dependência de código antigo, mais fácil se torna corrigir problemas, implementar novas funcionalidades e manter os 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 de ser acompanhado com atenção é a evolução das APIs.
Atualmente, muitos ambientes utilizam o GLPI integrado com:
sistemas de RH;
ERPs;
ferramentas de monitorização;
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 tem integrações críticas precisa de testar principalmente:
autenticação;
criação e atualização de tickets;
leitura de ativos;
pesquisas;
envio de documentos;
relacionamentos entre objetos;
permissões dos utilizadores de API;
retorno dos endpoints.
Não é seguro assumir que uma integração que funciona no GLPI 11 continuará a funcionar da mesma forma no GLPI 12 sem validação.
Segurança
A segurança continua a ser trabalhada dentro do projeto.
Já existem discussões e implementações relacionadas com controlos adicionais para operações sensíveis, revisão de permissões e reautenticação em determinadas ações.
Mesmo assim, é importante não esperar pelo GLPI 12 para manter o ambiente seguro.
As correções de segurança continuam a ser publicadas nas versões de manutenção do GLPI 11. Portanto, os ambientes de produção devem permanecer atualizados.
Também continuam válidas as recomendações básicas:
não alterar o core;
manter os plugins atualizados;
remover plugins abandonados;
rever permissões;
proteger ficheiros de configuração;
utilizar HTTPS;
manter o PHP e a base de dados atualizados;
executar as ações automáticas corretamente;
rever utilizadores de API;
manter cópia de segurança da base de dados e dos ficheiros.
Compatibilidade dos plugins
Este será provavelmente 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 tem uma versão compatível;
se o projeto continua a ser mantido;
quais as versões do PHP suportadas;
se existem alterações na base de dados;
se houve alterações nos hooks;
se o frontend do plugin continua a funcionar;
se as permissões continuam corretas;
se as ações automáticas funcionam;
se existe um processo oficial de migração.
Plugins abandonados ou que alteram diretamente o comportamento do core representam um risco maior.
Quem tem muitos plugins instalados deve começar os testes antes do lançamento da versão estável.
Customizações no core
Se o ambiente tem alterações diretamente nos ficheiros do GLPI, a atualização será mais complicada.
Essas alterações podem ser substituídas durante a atualização ou simplesmente deixar de funcionar.
O ideal é que as customizações sejam feitas com recurso a:
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.
Isto inclui:
ficheiros PHP modificados;
templates alterados;
CSS personalizado;
JavaScript personalizado;
alterações manuais na base de dados;
triggers;
views;
integrações;
plugins próprios.
Sem este levantamento, torna-se 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.
Pode ser usada para:
conhecer a nova interface;
testar plugins;
validar integrações;
analisar alterações técnicas;
verificar possíveis incompatibilidades;
testar fluxos de atendimento;
preparar a equipa para a migração.
Por ainda estar em desenvolvimento, podem ocorrer:
erros;
regressões;
alterações na base de dados;
funcionalidades incompletas;
alterações na interface;
incompatibilidade com plugins;
problemas de tradução;
alterações sem aviso prévio.
Também não recomendamos ligar uma versão de desenvolvimento diretamente à base de dados de produção.
O teste deve ser feito com uma cópia isolada da base de dados e dos ficheiros.
Estamos a acompanhar e a testar o GLPI 12
Na Nextools e na JMBA Soluções, já estamos a acompanhar o desenvolvimento do GLPI 12 e a executar testes com as versões disponíveis.
O nosso objetivo é identificar antecipadamente impactos em:
plugins;
integrações;
base de dados;
infraestrutura;
autenticação;
APIs;
customizações;
processo de atualização.
Para facilitar estes testes, disponibilizamos uma imagem Docker com a versão de desenvolvimento do GLPI 12.
Para transferir:
docker pull jmbasolucoes/glpi:12-dev
A imagem é destinada exclusivamente a testes.
Não deve ser utilizada em produção.
Com ela, é possível colocar rapidamente um ambiente a funcionar para:
avaliar a interface;
testar plugins;
validar LDAP e SSO;
testar integrações;
analisar o inventário;
rever formulários;
verificar regras;
identificar incompatibilidades.
Antes de testar uma atualização, utilize sempre uma cópia do ambiente.
Não ligue esta imagem à base de dados de produção.
Exemplo de ambiente Docker
Abaixo está um exemplo simples para colocar o GLPI 12 a funcionar com uma base de dados exclusiva 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, aceda a:
http://localhost:8080
Este 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 pela 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 registe:
versão;
programador;
finalidade;
criticidade;
estado de manutenção;
dependências;
compatibilidade.
Um plugin instalado e não utilizado deve ser removido.
Documente as integrações
Registe:
endpoint;
método de autenticação;
utilizador 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 mais fielmente possível a produção:
PHP;
base de dados;
plugins;
configurações;
autenticação;
regras;
notificações;
cron;
integrações.
Crie um roteiro de validação
Não basta abrir o GLPI e verificar se o ecrã carregou.
É necessário testar os principais processos:
abertura de tickets;
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á a preparar 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 as funcionalidades que estarão na primeira versão estável.
Também não é possível garantir que tudo o que aparece hoje em desenvolvimento será entregue exatamente da mesma forma.
O momento agora é de acompanhar, testar e identificar impactos.
Quem tem um ambiente simples terá provavelmente um processo de migração mais tranquilo.
Quem tem muitos plugins, integrações e alterações próprias precisa de começar a validação com antecedência.
Para iniciar os testes:
docker pull jmbasolucoes/glpi:12-devNos próximos conteúdos, vamos partilhar os testes que estamos a realizar, as diferenças em relação ao GLPI 11 e os problemas encontrados durante esta preparação.
Já está a testar o GLPI 12? Conte-nos o que funcionou, o que falhou e que alterações 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.
