Chat Tickets Ignored Ticket Numbering - edmozley/freeitsm GitHub Wiki

Chat tickets ignored your ticket numbering

Fixed in 3.1.0 · Found on a live install while testing ratings in Telegram · Modules: Tickets, Messaging, Forms, Workflows

What you saw

You set Tickets → Settings → Ticket numbering to your own format (say TICKET-{######}), and tickets raised by analysts, by email and on the portal followed it. A ticket opened by a Telegram message still came out as JNL-471-47705, the old random shape, as if the setting didn't exist.

What was wrong

When ticket numbering became configurable (#71), the three places that made a number (the ticket service, email collection and the portal) were moved onto one engine, TicketNumbering::next(). Its file header says why: a setting that reaches only some of the places a ticket is opened gives you two formats on one install.

It was six more places, not one. Each made its own random XXX-NNN-NNNNN and never asked the engine:

Where a ticket is opened	Function
WhatsApp, Telegram, Slack, Microsoft Teams, Mattermost	`messagingGenerateTicketNumber()` in `includes/messaging/ingest.php`
Web chat	the same function, called from `includes/webchat/webchat.php`
A form approved, or a form's "create a ticket" action	`catalogueGenerateTicketNumber()` in `includes/catalogue_approvals.php`
Merging into a new ticket	`mergeCreateTargetTicket()` in `includes/ticket_merge.php`
Splitting a ticket	`splitCreateTicket()` in `includes/ticket_split.php`
A workflow's Create a ticket action	`workflow/includes/engine.php`

On an install still using the default (random) format, nothing looked wrong, because the output had the same shape. That's why it lasted.

The fix

Every one of them now calls TicketNumbering::next($conn, $typeId, $tenantId) and passes what it knows. For the chat channels, that meant deciding the ticket's company before the number, the same reordering email collection needed under #71: per-company numbering and {COMPANY} both need it. messagingGenerateTicketNumber() stays as a one-line wrapper with a TRAP: comment, so the web chat and anything added later keep one name to call.

The demo-data importer keeps its own random numbers on purpose. Demo tickets shouldn't use up the numbers in your real sequence.

Found on the way: a reopened ticket still counted as closed

When a customer replies to a closed ticket and Reopen on customer reply is on, reopenTicketForCustomerReply() moves the ticket back to an open status. It did not clear closed_datetime, which the ticket service clears on any change to an open status. The ticket looked open but still counted as closed wherever that date is read, including reports and the chat lookup. That lookup would then have opened a second ticket for the customer's next chat message. It now clears the date.

Files

	File	Change
🟦	`includes/messaging/ingest.php`	company first, then `TicketNumbering::next()`
🟦	`includes/webchat/webchat.php`	the same
🟦	`includes/catalogue_approvals.php`	its own generator deleted
🟦	`includes/ticket_merge.php`, `includes/ticket_split.php`	the source ticket's type and company passed
🟦	`workflow/includes/engine.php`	the rule's ticket type passed (this action stores no company, so the default)
🟩	`includes/ticket_reply.php`	`closed_datetime = NULL` on reopen

How it was proved

All tests ran on the live install inside a transaction that was rolled back, and the numbering counters were checked to be unchanged afterwards.

Through the real chat ingest path, a Telegram message on an install set to TICKET-{######} opened TICKET-000124. Before the fix, the same path gave JNL-471-47705, which is the control.
With that ticket closed the way the ticket service closes one, the next message opened a new ticket, TICKET-000125.
reopenTicketForCustomerReply() on a closed ticket left status Open and closed_datetime NULL.
Merge into a new ticket and split each produced the next TICKET- number.
tests/ticket-numbering.php (61), tests/catalogue-approvals-grid.php (14) and tests/messaging-teams-mattermost.php (37) all pass.

What this means for you

New tickets from chat, forms, merges, splits and workflows now follow your numbering.
Existing tickets keep their numbers. If you want the old random ones in your format, Renumber existing tickets on the same settings page does it (should you?), and every old number keeps working in replies.
If you never changed the format, nothing is different.