O FormCreator foi, durante anos, o plugin mais instalado do GLPI - e no GLPI 11 deixa de existir como plugin. A pergunta deixou de ser "qual é melhor" e passou a ser operacional: em que versão está e como leva os formulários que já correm em produção para o novo módulo nativo sem partir o catálogo de serviços.
O que mudou do GLPI 10 para o GLPI 11
No GLPI 9 e 10, formulário personalizado é sinónimo de FormCreator: um plugin da comunidade (mantido pela Teclib) que entrega catálogo de serviços, campos condicionais, secções e geração automática de chamado a partir da resposta. A última linha standalone é a 2.13.x - a partir daí o desenvolvimento do plugin parou.
No GLPI 11, essa funcionalidade passou a módulo do core: o menu de Formulários, com editor visual, secções, perguntas condicionais e destinations (o que o formulário gera - chamado ou mudança). O FormCreator standalone não corre no 11. No lugar dele existe apenas um plugin de transição, o Formcreator Migration Tool (linha 3.0.x), cuja única função é levar os formulários antigos para o módulo nativo e depois declarar o FormCreator em fim de vida (EOL).
Comparativo direto
| Critério | FormCreator (GLPI 9/10) | Formulários nativos (GLPI 11) |
|---|---|---|
| Natureza | Plugin da comunidade (Teclib) | Módulo do core, sem plugin |
| Compatibilidade | GLPI 9 e 10 (linha 2.13.x) | GLPI 11+ |
| Editor visual | Secções, perguntas e condições | Editor com secções e condições nativas |
| Campos condicionais | Sim, por pergunta e por secção | Sim, condições nativas |
| Geração de chamado | "Target" (chamado, mudança, problema) | "Destinations" (chamado, mudança) |
| Onde guarda as definições | Tabelas glpi_plugin_formcreator_* | Tabelas glpi_forms_* |
| Onde guarda as respostas | Tabelas do próprio plugin | Conjunto de respostas (answers set) no core |
| Exportação/importação entre ambientes | Limitado ao próprio plugin | Nativo, em JSON, com reconciliação de dependências |
| Futuro / manutenção | Congelado (EOL após a migração) | Mantido pela Teclib no core |
| Migração 10 para 11 | Origem (Migration Tool 3.0.x) | Destino oficial da migração |
| Custo | Gratuito (GPL) | Incluído no core |
A migração não é um botão mágico
Existe, sim, migração oficial - e isso derruba o mito de que "é preciso recriar tudo à mão". O caminho é assistido: atualize o FormCreator para 2.13.10 ou superior ainda no GLPI 10, suba o GLPI 11 com o Migration Tool, confira o volume em Ferramentas > Formcreator EOL Info e corra a migração pela linha de comandos.
# 1) Ainda no GLPI 10: atualize o FormCreator para a versao 2.13.10 ou superior.
# 2) Suba o GLPI 11 e instale o "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Confira o volume a migrar no menu Ferramentas, item Formcreator EOL Info.
# 4) Corra a migracao pela CLI, como o utilizador do servidor web
# (Debian/Ubuntu usa www-data; RHEL/CentOS usa apache):
sudo -u www-data php bin/console migration:formcreator_plugin_to_core
# Ordem correta quando ha varios plugins legados no mesmo ambiente:
# Generic Objects, depois Fields e por ultimo o FormCreator.Antes de correr o que quer que seja, dimensione o trabalho. Um inventário rápido na base de dados diz quantos formulários, perguntas e alvos vai ter de conferir depois - e quais são os mais pesados:
-- Inventario ANTES de migrar: corra na base do GLPI (10, ou 11 com o
-- Migration Tool instalado) para dimensionar a conferencia pos-migracao.
SELECT
(SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS formularios,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_sections) AS seccoes,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_questions) AS perguntas,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets) AS alvos_de_chamado;
-- Os formularios com mais perguntas sao os que mais exigem conferencia
SELECT f.name AS formulario, COUNT(q.id) AS perguntas
FROM glpi_plugin_formcreator_forms f
LEFT JOIN glpi_plugin_formcreator_sections s
ON s.plugin_formcreator_forms_id = f.id
LEFT JOIN glpi_plugin_formcreator_questions q
ON q.plugin_formcreator_sections_id = s.id
WHERE f.is_deleted = 0
GROUP BY f.id, f.name
ORDER BY perguntas DESC;O que a ferramenta migra bem é estrutura e conteúdo: secções, perguntas e tipos de campo. Onde pede conferência humana é na lógica de encaminhamento - o FormCreator usava o "target ticket" para definir categoria, template, grupo e intervenientes do chamado gerado; no nativo isso passa a destinations, e a importação sinaliza as dependências que faltam no destino (entidade, categoria) para mapear antes de concluir.
O trade-off que aparece na sustentação
Na gestão de parques GLPI para clientes, o erro mais comum não é técnico, é de expectativa: alguém corre o comando de migração, os formulários aparecem no menu novo e a equipa dá a tarefa por terminada. Não está. O que migra é a casca; o miolo - que chamado é aberto, em que categoria, para que grupo, com que template - é justamente o que exige revisão. Por isso migramos sempre para homologação primeiro, submetemos um chamado de teste por formulário e comparamos o encaminhamento com o comportamento do FormCreator antigo, campo a campo.
Dois detalhes apanham quem o faz à primeira. Primeiro: as tabelas glpi_plugin_formcreator_* continuam na base depois da migração - nada é apagado, passam a fonte de leitura/EOL e não desaparecem, por isso "desapareceu tudo" costuma ser só o menu que mudou de sítio. Segundo: os formulários nativos ganham IDs (e UUIDs) novos, portanto qualquer ligação direta, favorito do portal ou atalho de self-service que apontava para um formulário do FormCreator deixa de funcionar e tem de ser reapontado. E há o pré-requisito silencioso: se o FormCreator estiver numa versão anterior à 2.13.10, o Migration Tool simplesmente não vê os formulários - atualizar antes de tudo é o que evita a migração "vazia".
Veredicto por cenário
Fique no FormCreator quando o ambiente é GLPI 9 ou 10 e não há migração para o 11 no horizonte próximo. Nessas versões é a opção madura e sem substituto para catálogo de serviços e formulários personalizados. Recomendação prática: mantenha-o em 2.13.10 ou superior mesmo sem migrar agora - é o que deixa a porta da migração aberta quando o 11 chegar.
Use os formulários nativos quando está no GLPI 11 (ou vai migrar). Aqui não há decisão a tomar: o FormCreator standalone não corre no 11, e o módulo nativo é o caminho - sem plugin para gerir na atualização, com exportação/importação de formulários entre ambientes em JSON (algo que o FormCreator nunca fez nativamente) e reconciliação de dependências no destino.
A migrar de 10 para 11, use a ferramenta oficial, mas trate como projeto e não como comando: inventarie os formulários, dimensione a conferência pela quantidade de perguntas e condições, migre para homologação, valide o encaminhamento de cada formulário e só então promova. Havendo vários plugins legados, respeite a ordem que a própria documentação indica: Generic Objects, depois Fields, depois FormCreator.
Custo e esforço
A licença não é o eixo da decisão: FormCreator e formulários nativos são gratuitos, e no 11 o nativo já vem no core. O custo real é o da migração e da conferência. A parte automática - correr o bin/console - leva de minutos a algumas dezenas de minutos conforme o volume. A parte que consome tempo de gente é validar encaminhamento e recriar a lógica de destino que não veio 1:1. Como intervalo honesto: para poucos formulários simples, a migração inteira cabe numa tarde; para dezenas de formulários com muitas condições, intervenientes e templates, planeie dias de conferência em homologação antes de libertar em produção.
Na NexTool implementamos e sustentamos GLPI em clientes nas duas gerações e conduzimos a migração do FormCreator para os formulários nativos sem derrubar o catálogo de serviços. Se vai sair do GLPI 10 e não quer descobrir na produção o que a migração não trouxe, os nossos projetos de implementação e migração cobrem esse caminho de ponta a ponta.
Revisto pela equipa NexTool Solutions.
