Skip to content

Fix/transfer log followup#2

Merged
tsmr merged 3 commits into
pluginsGLPI:masterfrom
giovanny07:fix/transfer-log-followup
Jun 24, 2026
Merged

Fix/transfer log followup#2
tsmr merged 3 commits into
pluginsGLPI:masterfrom
giovanny07:fix/transfer-log-followup

Conversation

@giovanny07

Copy link
Copy Markdown

Summary

  • Wrong item type for transfer log: The transfer was logged as a TicketTask,
    which represents work to be done. ITILFollowup is the correct type to record
    an event that has already occurred (the transfer itself).
  • Unified content: Entity name, group name (when selected), and justification
    (when provided) are now built into a single followup entry instead of relying
    on fragmented string concatenation. Each section is guarded with !empty() so
    it only appears when actually set.

Changes

src/Ticket.php:

  • Replaced use TicketTask / use Planning with use ITILFollowup.
  • Replaced the TicketTask::add() call with ITILFollowup::add() using
    itemtype = Ticket::class and items_id.
  • Refactored content building to append group and justification only when present.

Test plan

  • Transfer a ticket with no group and no justification — one private followup is
    created with "Escalation to [entity]"
  • Transfer with a group selected — followup includes "in the group [name]"
  • Transfer with justification text — followup includes the justification after a
    line break
  • Transfer with both group and justification — single followup contains all three
    parts in one entry
  • Confirm no TicketTask entries are created by the plugin on transfer

@dhrzic

dhrzic commented May 12, 2026

Copy link
Copy Markdown

On v10 when automatic task is added, notification is not being generated, can you also check this? Or maybe add a dedicated notification for this event?

@giovanny07

Copy link
Copy Markdown
Author

The original TicketTask relied on the add_task notification event, which is not enabled by default in most GLPI setups. ITILFollowup uses the add_followup event, which is enabled by default. With is_private = true, the notification is sent only to tech-side actors — the requester is still informed of the transfer via the update_ticket event that fires when the entity changes.
A dedicated plugin notification event (e.g. ticket_transferred) would allow finer control over recipients and could be added as a separate enhancement.

@tsmr

tsmr commented May 22, 2026

Copy link
Copy Markdown
Collaborator

Please add an option into plugin setup for choose to create a followup or a task

giovanny07 and others added 3 commits June 23, 2026 14:46
Transfer logging used TicketTask (task) which is intended for work to be
done. ITILFollowup (followup) is the correct type to record an event that
already happened. Also consolidates entity, group, and justification into
a single followup instead of relying on fragmented string concatenation,
and guards the group/justification sections with !empty() so they only
appear when actually set.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Admins can now choose per destination entity whether the transfer is
logged as a followup (default) or as a task. The choice is stored in a
new log_type column (0=followup, 1=task). A migration guard adds the
column on existing installations via ALTER TABLE.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@giovanny07 giovanny07 force-pushed the fix/transfer-log-followup branch from 48b92ec to 66737e2 Compare June 23, 2026 19:46
@tsmr tsmr merged commit 7533a55 into pluginsGLPI:master Jun 24, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants