Fix/transfer log followup#2
Conversation
- When keep_category is enabled and the category exists in the target entity, explicitly include itilcategories_id in the update payload so GLPI core does not reset it when the entity changes. - Fix undefined variable $ticket_category in the same code path, which caused the mandatory-category check to incorrectly block the transfer. - Use !empty() on group_choice to avoid PHP warning when the key is absent from POST (group not required / not selected). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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>
|
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? |
|
The original |
|
Please add an option into plugin setup for choose to create a followup or a task |
Summary
TicketTask,which represents work to be done.
ITILFollowupis the correct type to recordan event that has already occurred (the transfer itself).
(when provided) are now built into a single followup entry instead of relying
on fragmented string concatenation. Each section is guarded with
!empty()soit only appears when actually set.
Changes
src/Ticket.php:use TicketTask/use Planningwithuse ITILFollowup.TicketTask::add()call withITILFollowup::add()usingitemtype = Ticket::classanditems_id.Test plan
created with "Escalation to [entity]"
line break
parts in one entry
TicketTaskentries are created by the plugin on transfer