Expand the number of fields data

Your track of thinking is correct. The file you indicated governs what is being send for this particular event, and if you wish to add simple fields like Opening Date, you just take them from the CommonDBTM schema for the particular item and include them into the method:

protected static function makeMessage(CommonDBTM $item): array
{
    return [
        'ticket_id' => self::getTicketId($item),
        'subject' => $item->input['name'],
        'content' => $item->input['content'],
        'opening_date' => $item->input['date'], // added line
    ];
}

For example, the Ticket schema looks like this:

{
  "id": 0,
  "_glpi_csrf_token": "[token]",
  "_skip_default_actor": "1",
  "_tickettemplate": "1",
  "_predefined_fields": "",
  "name": "Test name",
  "content": "&#60;p&#62;Test&#60;/p&#62;",
  "date": "2023-04-21 09:30:00",
  "type": "2",
  "itilcategories_id": "0",
  "status": "1",
  "requesttypes_id": "1",
  "urgency": "3",
  "impact": "3",
  "priority": "3",
  "actiontime": "0",
  "validatortype": "user",
  "users_id_validate": [
    "2"
  ],
  "_add_validation": "0",
  "_notifications_actorname": "",
  "_notifications_actortype": "",
  "_notifications_actorindex": "",
  "_notifications_alternative_email": "",
  "my_items": "",
  "itemtype": "",
  "items_id": "0",
  "slas_id_tto": "0",
  "slas_id_ttr": "0",
  "olas_id_tto": "0",
  "olas_id_ttr": "0",
  "_link": {
    "tickets_id_1": 6,
    "link": "1",
    "tickets_id_2": "0"
  },
  "_no_history": "",
  "_add": "",
  "_users_id_requester": {
    "_actors_2": "2"
  },
  "_users_id_requester_notif": {
    "use_notification": {
      "_actors_2": "0"
    },
    "alternative_email": {
      "_actors_2": ""
    }
  },
  "_users_id_requester_deleted": [],
  "_groups_id_requester": [],
  "_groups_id_requester_deleted": [],
  "_suppliers_id_requester": [],
  "_suppliers_id_requester_notif": {
    "use_notification": [],
    "alternative_email": []
  },
  "_suppliers_id_requester_deleted": [],
  "_users_id_observer": [],
  "_users_id_observer_notif": {
    "use_notification": [],
    "alternative_email": []
  },
  "_users_id_observer_deleted": [],
  "_groups_id_observer": [],
  "_groups_id_observer_deleted": [],
  "_suppliers_id_observer": [],
  "_suppliers_id_observer_notif": {
    "use_notification": [],
    "alternative_email": []
  },
  "_suppliers_id_observer_deleted": [],
  "_users_id_assign": {
    "_actors_2": "2"
  },
  "_users_id_assign_notif": {
    "use_notification": {
      "_actors_2": "0"
    },
    "alternative_email": {
      "_actors_2": ""
    }
  },
  "_users_id_assign_deleted": [],
  "_groups_id_assign": [],
  "_groups_id_assign_deleted": [],
  "_suppliers_id_assign": [],
  "_suppliers_id_assign_notif": {
    "use_notification": [],
    "alternative_email": []
  },
  "_suppliers_id_assign_deleted": [],
  "users_id_lastupdater": "2",
  "users_id_recipient": "2",
  "entities_id": "0",
  "global_validation": "1",
  "_locations_id_of_requester": "0",
  "_locations_id_of_item": "0",
  "_contracts_id": "0",
  "_date_creation_calendars_id": [
    "1"
  ],
  "users_default_groups": "0",
  "_no_rule_matches": "1"
}

As you can see, there are some data ready to use, like the aforementioned date.

The issue becomes more complicated when you want to include things that are not in the basic CommonDBTM provided by the event handler. For such use cases, I would add an empty method to PluginFpwebhookEventBase that would search for the desired data elsewhere (via regular queries) - and implement it in any of the classes that would need it. Alternatively, you can simply override PluginFpwebhookEventBase.getTicketData() to get the needed data, as it is done in PluginFpwebhookTicketCreated.

I am marking this issue for investigation as a possible enhancement / new feature.

FutureProcessing / glpi-webhook

Expand the number of fields data #8