NexTool Solutions

Um campo personalizado no GLPI é uma decisão de arquitetura, não um clique. A pergunta certa não é "Fields ou nativo?", mas sim: o dado que precisa de guardar é um atributo de algo que já existe, ou é uma coisa nova com vida própria? Essa resposta define a ferramenta - e o custo que paga nos próximos anos.

O que cada abordagem realmente resolve

O plugin Fields (mantido pela Teclib) pendura campos extra em tipos de item que já existem no GLPI: chamado, computador, utilizador, contrato, fornecedor. Cria um contentor (um bloco de campos), escolhe em que tipos aparece e adiciona campos de texto, lista pendente, data, número, sim/não e URL. Continua a ser a forma prática de dizer "todo o chamado precisa de um campo Centro de Custo".

Os objetos personalizados do GLPI 11 (ativos personalizados) resolvem outro problema: criar um tipo de item novo diretamente no core, sem plugin. É o substituto oficial do antigo GenericObject. Define "Veículo", "Sala de Reuniões" ou "Equipamento de Laboratório" com campos próprios, e passa a comportar-se como um ativo de primeira classe: entra no inventário, liga-se a chamados, aparece em relatórios.

Resumindo a fronteira: Fields adiciona atributos a algo que existe; um objeto nativo cria a entidade. Confundir os dois está na origem de quase toda a dor de manutenção que aparece depois.

Comparativo direto

Onde os dados vivem (e porque isso importa)

Cada contentor do Fields torna-se uma tabela dedicada na base de dados, com uma linha por item e uma coluna por campo. Antes de decidir, vale a pena ver o que já existe no ambiente:

-- Onde o plugin Fields guarda os valores: uma tabela por contentor,
-- com uma linha por item e uma coluna por campo personalizado.
SELECT table_name AS tabela_de_contentor
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'glpi_plugin_fields_%'
ORDER BY table_name;

-- Definicoes: contentores (a que tipos se aplicam) e os campos de cada um
SELECT c.name AS contentor, c.itemtypes, f.name AS campo, f.type
FROM glpi_plugin_fields_containers c
JOIN glpi_plugin_fields_fields f
  ON f.plugin_fields_containers_id = c.id
ORDER BY c.name, f.ranking;

Isto importa por dois motivos operacionais. Primeiro: cada campo do Fields marcado como pesquisável torna-se uma search option, e o motor de pesquisa do GLPI resolve-a com um LEFT JOIN adicional na tabela do contentor. Num cliente com 15 ou mais contentores no Ticket, a lista de chamados começa a ficar lenta - não pelo volume de dados, mas pela quantidade de JOINs no SELECT da pesquisa. Segundo: os objetos nativos escrevem no schema do core, portanto saem em exportação, API e relatório com o mesmo tratamento dos campos padrão, sem tabela paralela para reconciliar.

O trade-off que aparece na sustentação

Na gestão de parques GLPI para clientes, o custo real do Fields não é instalar - é o dia da atualização maior. O Fields é uma dependência dura: numa migração de GLPI 10 para 11, o ambiente só arranca quando existe versão do plugin compatível com o novo core. Já seguramos a janela de atualização de um cliente à espera de o plugin publicar a build compatível, com dezenas de contentores em produção que não podíamos simplesmente desligar. Um objeto nativo não tem esse bloqueio: é o core, sobe com ele.

Dois erros comuns que corrigimos com frequência. O primeiro é modelar uma entidade inteira como uma pilha de campos no chamado - "Contrato de manutenção" a tornar-se 12 campos Fields no Ticket, impossível de listar, filtrar ou relacionar bem; ali cabia um objeto (ou o próprio módulo de Contratos do GLPI). O segundo é o oposto: criar um ativo personalizado inteiro para o que eram dois atributos organizacionais num tipo existente - complexidade de modelação sem retorno. E um alerta que damos sempre: esconder um campo do Fields por perfil é apresentação, não segurança. O valor continua na base de dados e escapa por API, exportação ou pesquisa. Se o dado for sensível, o controlo tem de estar noutro lugar.

Veredicto por cenário

Use o Fields quando o dado é atributo de um tipo que já existe e não quer gerir um tipo novo: centro de custo e projeto no chamado, património interno no computador, número de funcionário no utilizador, campos obrigatórios ou condicionais por categoria de chamado. É rápido, sem downtime e sem migração de schema para administrar.

Use um objeto personalizado nativo quando a "coisa" tem vida própria e vai listá-la, filtrá-la e ligá-la a chamados como um item: veículos, salas, ativos de laboratório, equipamentos que não cabem em nenhum tipo padrão. E, obrigatoriamente, quando estiver a sair do GenericObject na migração para o GLPI 11 - é o caminho de substituição oficial.

Os dois convivem. É legítimo ter um ativo personalizado para a entidade e, ainda assim, usar o Fields para pendurar um ou outro atributo organizacional em chamados que referenciam esse ativo. O que não vale é usar um para fazer o trabalho do outro.

Custo e esforço

Licença: ambos são gratuitos (GPL). O custo verdadeiro é de manutenção. O Fields cobra em risco de dependência a cada atualização maior e em peso de pesquisa à medida que os contentores crescem. Um objeto nativo cobra em modelação inicial - desenha um tipo, não adiciona apenas um campo - mas depois não pesa na atualização nem num JOIN paralelo. Como intervalo honesto: adicionar um campo Fields leva minutos; modelar um ativo personalizado bem feito leva de algumas horas a um dia, contando campos, perfis e integração com inventário.

Na NexTool implementamos e sustentamos as duas abordagens no GLPI de clientes. Se está a decidir entre pendurar mais campos ou modelar um objeto - ou precisa de sair do GenericObject sem partir o histórico - a nossa consultoria de GLPI ajuda a fechar essa decisão antes de se tornar dívida técnica.

Revisto pela equipa NexTool Solutions.