Replies: 1 comment
|
Hi @dschipfel This is now built and on main! You asked for a range of options rather than one opinion, so I went and looked at how the other systems do it first. ServiceNow is the best of them: a prefix, a starting number and a digit count, held per table so incidents and requests each get their own run. osTicket has a format string with Tickets -> Settings -> Ticket numbering
On the digit width, which was the thing worth getting right: it is a floor, never a limit. Existing tickets keep their numbers, and every reference FreeITSM has ever issued goes on working. That is the part I want to be clearest about, because it is where this feature could have done real damage. The reference in an email subject is looked up rather than recognised by its shape, so an install can carry numbers from every format it has ever used and they all keep threading correctly. Getting there meant fixing something first: the old format was hardcoded into the email-subject parser in seven places, and changing the format without that fix would have silently turned every reply to every historical email into a brand-new ticket. You can also renumber existing tickets, if you have just migrated and want the whole estate to look consistent. It rewrites every ticket oldest first, and it is safe for one reason: every number a ticket has ever had is remembered and keeps resolving to it forever, so a reply quoting an old reference still lands on the right ticket. That is the same mechanism that already makes ticket merges safe, and a retired number is never handed to a different ticket. It previews before it writes, using the same code that would do the work, and the button stays off until you have looked at that preview. Honestly though, most people should not renumber. Old tickets are mostly finished tickets, nothing in FreeITSM parses the shape of a reference, and in a fortnight the old ones have dropped off the bottom of everyone's view. There is a page below that argues that case properly. On multi-company installs, since it comes up immediately: if someone at company A emails in and gets Documentation:
Two things I would flag as genuine limitations rather than polish: Per-type counting only works properly where tickets have a type. Tickets arriving by email or through the portal do not have one until an analyst sets it, so It is English-only so far. The other 23 locales still need the strings. Thanks for the request - the framing of it, offering a range rather than picking one, is what made it worth building properly. |
Uh oh!
There was an error while loading. Please reload this page.
Many organizations rely on ticket numbers for communication between end users, support agents, and external service providers. Therefore, having a clear and human-readable ticket numbering scheme can significantly improve usability.
Current challenge
Ticket IDs are currently generated using identifiers that can be difficult to read, remember, or communicate. In daily operations, users and agents often reference tickets by phone, email, meetings, or documentation, where a simple sequential number is much easier to work with.
Suggested solution
Introduce a configurable ticket numbering format that administrators can define according to their organization's needs.
Examples:
or
Possible configuration options
Benefits
For many organizations, a ticket number such as TICKET-01542 is much easier to recognize and communicate than a randomly generated identifier. This small enhancement could greatly improve the day-to-day user experience without changing the underlying ticket system functionality.
All reactions