NexTool Solutions

No GLPI 11 o catálogo de serviços deixou de ser um plugin e passou a fazer parte do núcleo - mas o que deita a maioria das implementações abaixo não é falta de funcionalidade, e sim um formulário publicado que nenhum utilizador consegue ver. Na sustentação de ambientes GLPI de clientes, esse é o primeiro sintoma a aparecer: "o catálogo está vazio" quando, na base de dados, os formulários existem e estão ativos. Este guia mostra como montar um serviço de ponta a ponta com os recursos nativos e como diagnosticar as armadilhas antes que o utilizador se queixe.

No GLPI 11 o catálogo é nativo - e tem endereço próprio

Até ao GLPI 10, catálogo de serviços era sinónimo de FormCreator. No GLPI 11 os formulários entraram no núcleo e, com eles, chegou um Catálogo de Serviços a sério: uma página self-service, servida pela rota /ServiceCatalog, onde o utilizador navega pelos serviços organizados por categoria e abre o formulário certo. Os formulários vivem em Administração > Formulários e cada serviço do catálogo é um formulário com quatro peças que têm de estar alinhadas:

• Formulário (glpi_forms_forms): o serviço em si, com nome, descrição e categoria.
• Perguntas (glpi_forms_questions): os campos que o utilizador preenche, com obrigatoriedade e condições.
• Controlo de acesso (glpi_forms_accesscontrols_formaccesscontrols): quem vê o serviço no catálogo.
• Destino (glpi_forms_destinations_formdestinations): o que é criado no envio - um ticket, uma mudança ou um problema.

Montar um serviço de ponta a ponta

A ordem importa. Saltar o separador de Controlo de acesso é o erro que mais retrabalho gera. Para cada serviço:

1. Crie o formulário e associe-o a uma categoria enxuta (no máximo dois níveis; glpi_forms_categories é uma árvore, e uma árvore funda torna-se um labirinto).
2. Adicione apenas as perguntas que vai mesmo usar no atendimento. Um campo bonito que ninguém lê no ticket é atrito para o utilizador.
3. Configure o Controlo de acesso: a estratégia AllowList restringe o serviço a perfis, grupos ou utilizadores; a DirectAccess gera uma ligação direta (útil para um fornecedor externo). Sem uma política de acesso ativa, o formulário não aparece no catálogo.
4. Defina o Destino: o itemtype FormDestinationTicket cria um ticket; existem também FormDestinationChange e FormDestinationProblem. No destino mapeia a categoria ITIL, o grupo responsável e o requerente do item gerado.
5. Ative o formulário (is_active) e teste com um utilizador self-service real, não com a sua conta de administrador.

A armadilha que faz o catálogo "desaparecer"

Na sustentação, o pedido recorrente é "publiquei o serviço e o utilizador não o vê". Na quase totalidade dos casos a causa é a mesma: o formulário está com is_active = 1, mas não tem nenhuma política de Controlo de acesso ativa. O GLPI 11 trata a visibilidade e a publicação como coisas separadas - publicar não chega, é preciso ter pelo menos uma AllowList ou DirectAccess ativa. E o GLPI não emite qualquer aviso: para o técnico o formulário está "no ar", para o utilizador o catálogo está vazio. Esta é a primeira consulta que executamos num onboarding de sustentação, antes de discutir taxonomia:

-- Formularios PUBLICADOS que NAO aparecem no catalogo self-service:
-- estao ativos (is_active=1) mas sem NENHUMA politica de acesso ativa.
-- Existem, contam no total e sao invisiveis para o utilizador final.
SELECT f.id, f.name, f.usage_count
FROM glpi_forms_forms f
LEFT JOIN glpi_forms_accesscontrols_formaccesscontrols ac
       ON ac.forms_forms_id = f.id
      AND ac.is_active = 1
WHERE f.is_active  = 1
  AND f.is_deleted = 0
  AND f.is_draft   = 0
  AND ac.id IS NULL
ORDER BY f.usage_count DESC;

Um detalhe que só morde quem migrou a sério: ao trazer formulários do FormCreator para o núcleo do GLPI 11, a visibilidade por perfil do FormCreator não se transforma automaticamente numa AllowList. O formulário chega ativo, mas sem política de acesso - ou seja, invisível. Já auditámos catálogos acabados de migrar com dezenas de serviços nesse limbo, e o cliente jurava que "a migração perdeu os formulários". Não perdeu: estavam lá, apenas sem ninguém que os pudesse ver.

Visão do cliente vs visão técnica: onde vive cada uma

O catálogo tem duas camadas e, no GLPI 11, ficam em sítios diferentes do formulário:

• A visão do cliente vive no separador Catálogo de serviços (título, descrição amigável, categoria, ilustração) e no Controlo de acesso (quem vê). É o que aparece em /ServiceCatalog.
• A visão técnica vive no Destino: categoria ITIL, grupo técnico e requerente do ticket gerado. O SLA não vive no formulário - é aplicado sobre o ticket criado, por uma regra de negócio ou pela categoria ITIL.

O erro comum aqui é tentar "pôr o SLA no formulário". Esse campo não existe: o formulário só cria o item; quem carrega o prazo é o ticket. A matriz que usamos para decidir a configuração de cada serviço:

Meça pelo uso, não pelo tamanho

Um bom catálogo não é um catálogo grande. Cada formulário do GLPI 11 tem um contador nativo de uso (usage_count), incrementado a cada envio - use-o para priorizar e podar. Um serviço que ninguém aciona há meses só engorda o menu e afunda os que importam. A consulta de poda que executamos no nosso ciclo trimestral de revisão:

-- Candidatos a poda: publicados ha mais de 90 dias e nunca usados.
-- Um menu enxuto ajuda o utilizador a encontrar o servico certo mais depressa.
SELECT id, name, usage_count, date_creation
FROM glpi_forms_forms
WHERE is_active  = 1
  AND is_deleted = 0
  AND usage_count = 0
  AND date_creation < (NOW() - INTERVAL 90 DAY)
ORDER BY date_creation;

Comece pelos dez serviços mais pedidos, use nomes que o utilizador perceba ("Pedir um portátil", não "Aprovisionamento de ativo") e reveja o catálogo a cada trimestre com o usage_count à mão. É assim que o catálogo deixa de ser montra parada e passa a ser a verdadeira porta de entrada do service desk.

Precisa de estruturar (ou resgatar) um catálogo de serviços no GLPI 11 com a visibilidade sob controlo e os destinos mapeados ao seu fluxo? Conheça os projetos de implementação da NexTool.

Este conteúdo foi produzido com o auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.