From 0eff7d70f786fa7772a74ceaea14c632985ce3ae Mon Sep 17 00:00:00 2001 From: Gemini Date: Mon, 29 Jun 2026 22:07:19 -0300 Subject: [PATCH] =?UTF-8?q?docs:=20README=20e=20CHANGELOG=20cobrindo=20v?= =?UTF-8?q?=C3=ADnculo=20por=20Entidade=20(1.4.0)=20+=20link=20da=20doc=20?= =?UTF-8?q?de=20API?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- CHANGELOG.md | 10 ++++++++++ README.md | 23 ++++++++++++++++++++--- 2 files changed, 30 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index bec7caf..edba176 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,16 @@ Todas as mudanças relevantes deste plugin são documentadas aqui. O formato segue [Keep a Changelog](https://keepachangelog.com/pt-BR/1.0.0/) e o versionamento segue [SemVer](https://semver.org/lang/pt-BR/). +## [1.4.0] + +### Adicionado +- Vínculo **Entidade GLPI → Projeto Redmine** (1:1, match exato, sem herança de árvore), via aba Redmine em Administração → Entidades — para clientes de suporte recorrente cujos chamados nascem na entidade, sem projeto. +- Documentação de API para desenvolvedores (`docs/API.md`). + +### Alterado +- Resolução do projeto Redmine no hook passa a considerar, além do projeto vinculado, a **entidade** do chamado como fallback. +- Templates do tab generalizados (`owner_field`/`owner_id`) para reuso entre Projeto e Entidade. + ## [1.3.0] ### Adicionado diff --git a/README.md b/README.md index eb26009..a51f45f 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,8 @@ Equipes que **executam o atendimento no GLPI** mas **gerenciam projetos e horas ## Como funciona ``` -Projeto GLPI ───(vínculo manual na aba "Redmine")──▶ Projeto Redmine +Projeto GLPI ──(vínculo na aba "Redmine")──▶ Projeto Redmine ┐ +Entidade GLPI ──(vínculo na aba "Redmine")──▶ Projeto Redmine ┘ (1:1) Chamado GLPI ──────────────────────────────────────▶ 1 ISSUE no Redmine • título = título do chamado @@ -27,6 +28,7 @@ TicketTask "Feito" ──────────────────── • comentário = descrição da tarefa ``` +- **Dois pontos de vínculo**: o chamado é direcionado ao projeto Redmine pelo **Projeto** GLPI ao qual está ligado **ou**, na ausência de projeto, pela **Entidade** do chamado (clientes de suporte recorrente). Sem vínculo (projeto nem entidade), nada é enviado. - **Uma issue por chamado**: o chamado nasce e "morre" no GLPI; para o Redmine importam as **horas** e o **andamento**. - **Tempo só sobe quando a tarefa é concluída** (`Feito`): enquanto não concluída, fica apenas no GLPI. - **Autores corretos**: a issue é criada como o **técnico atribuído** e cada lançamento de tempo como o **técnico que o registrou**, usando *impersonation* do Redmine — não tudo como "admin". @@ -34,6 +36,7 @@ TicketTask "Feito" ──────────────────── ## Funcionalidades - ✅ Vínculo de Projeto GLPI ↔ Projeto Redmine (criar novo ou vincular existente), com módulos, subprojeto e visibilidade. +- ✅ Vínculo de **Entidade GLPI ↔ Projeto Redmine** (1:1) — para clientes de suporte recorrente que abrem chamados sem projeto. - ✅ Criação automática de **issues** a partir dos chamados, com valores padrão (tracker, prioridade, atividade) e **categoria por projeto**. - ✅ Lançamento automático de **tempo** das tarefas concluídas (idempotente — sem duplicar). - ✅ **Mapa de status** Chamado GLPI → Status Redmine, totalmente configurável. @@ -67,20 +70,34 @@ Acesse **Configurar → Plugins → Redmine Integration**: 4. **Mapa de status** — para cada status de chamado do GLPI, escolha o status correspondente no Redmine. 5. **Mapeamento de usuários** — usuários com o **mesmo e-mail** nos dois sistemas são associados automaticamente; cadastre *overrides* apenas para as exceções. -Depois, em cada **Projeto** do GLPI, abra a aba **Redmine** para vincular ao projeto correspondente no Redmine e definir a **categoria padrão**. +Depois, defina os vínculos nas abas **Redmine**: +- Em cada **Projeto** do GLPI (`Ferramentas → Projetos`): aba **Redmine** → vincular/criar o projeto Redmine + **categoria padrão**. +- Em cada **Entidade** de cliente recorrente (`Administração → Entidades`): aba **Redmine** → vincular/criar o projeto Redmine (1:1) + **categoria padrão**. ## Fluxo de uso +**Cenário A — Projetos** 1. Vincule o Projeto GLPI ao Projeto Redmine (aba Redmine do projeto). 2. A partir de uma **tarefa de projeto**, crie um **chamado** ("Criar chamado a partir desta tarefa de projeto"). 3. No chamado, o técnico registra **tarefas (TicketTask)** e o tempo gasto. 4. Ao marcar a tarefa como **Feito**, o plugin cria/atualiza a issue no Redmine e lança o tempo — com o autor correto. +**Cenário B — Clientes de suporte recorrente (Entidade)** +1. Vincule a **Entidade** do cliente ao Projeto Redmine (aba Redmine da entidade). +2. O cliente abre um **chamado** diretamente na sua entidade (sem projeto). +3. O técnico registra **tarefas (TicketTask)** e o tempo gasto. +4. Ao marcar a tarefa como **Feito**, o plugin resolve o projeto Redmine **pela entidade** e cria a issue + lança o tempo. + +## Documentação para desenvolvedores + +Contrato de API completo (o que sai do GLPI, como entra no Redmine — endpoints, payloads, cabeçalhos, mapeamento de campos, impersonation e exemplos): veja [`docs/API.md`](docs/API.md). + ## Notas e limitações - O tempo de uma tarefa é lançado **uma única vez** (ao concluir). Edições posteriores de horas não re-sincronizam. - A *impersonation* exige que o usuário Redmine exista e seja **membro do projeto** — o plugin adiciona o técnico automaticamente; se não houver usuário correspondente, o lançamento usa o admin (com aviso em log). -- Categorias do Redmine são **por projeto**: a categoria padrão é definida no vínculo de cada projeto. +- Categorias do Redmine são **por projeto**: a categoria padrão é definida no vínculo de cada projeto/entidade. +- O vínculo por **Entidade** é **1:1 e por correspondência exata** — não há herança pela árvore de entidades. O chamado precisa nascer na própria entidade vinculada. ## Suporte