Reading Long Tickets

Reading Long Tickets

Everything FreeITSM does to keep a ticket readable once the email chain has got away from it. All of it comes from discussion #104, and all of it is configured in one place: Tickets → Settings → General.

For developers: Reading Long Tickets — Developer Guide covers the three automatic behaviours, and Ticket AI Reading — Developer Guide covers the summary and the briefing.

The one rule

Nothing here ever deletes, hides or replaces anything. Every message stays in the page, in full, the whole time — the most any of it does is fold something away behind one tap.

That is not politeness, it is the design constraint. Deciding where quoted history ends is genuinely hard: every mail client marks a quoted chain differently, plenty do not mark it at all, and a forwarded message can look identical to a reply. Any approach is right most of the time and wrong some of the time. So a wrong judgement about what is noise has to cost you a click, never a fact.

The five things

	What it does	Default
Shorten long messages	A message taller than a limit you set is clipped, with Show more.	On, ~12 lines
Fold older messages	Beyond N recent messages, the rest go behind one "{n} older messages" line.	On, 6 shown
Flag repeats	A message that has arrived before is folded away, with a note saying which one it matches.	On
AI summary	A few lines at the top: where things stand, what was asked, what has been done, who owes the next move.	Off
Read it for me	A briefing on a ticket you have never seen.	Off

The last two are off because, unlike the first three, they cost money — they use your own AI provider's key. A feature that starts billing you when you upgrade is not a good surprise.

---

Shortening long messages

A long email is clipped after roughly the number of lines you choose, with a Show more link. Three things you can adjust:

• The newest message is always shown in full. It is the one you opened the ticket to read. You can switch this off if you would rather everything behaved the same way.
• Quoted history is shortened separately. A two-line reply with a thousand lines of chain underneath it is short by any line count and still unreadable.
• What you open stays open, on that device, so scrolling back to a ticket does not mean expanding the same message again. This is remembered in your browser and never leaves it.

Why "about" 12 lines? The limit is applied to how tall the message actually renders, not how many lines of source it has. A vendor notification laid out in tables can be a handful of lines of code and render the height of your desk. Stating the setting in lines keeps it something you can reason about; measuring the rendered height is what makes it match what you actually scroll past.

Folding the older part

Shortening a long message does nothing for a ticket that is long because it holds eighty short ones — every message is under the limit and the ticket is still unreadable.

So the most recent messages stay as they are and everything before them folds behind a single line: "14 older messages". Click it to open them all. The count is stated so nobody has to wonder what is behind it, and the messages are in the page the whole time — this moves them, it does not drop them.

Set how many recent messages stay open under Recent messages to keep open.

Flagging repeats

A long ticket is more often the same message five times than one long message: a resend, a distribution list delivering twice, a bounce carrying the original back, an auto-reply quoting the lot.

A message that has arrived before is folded away with a line saying which earlier one it matches and when:

Identical to the message from Mon 31.08.2026 22:28 Nearly identical to the message from Mon 31.08.2026 22:28

"Nearly identical" catches the case an exact comparison misses — somebody resending with one line added at the bottom. Very short messages are never flagged: "Thanks" is not a duplicate of "Thanks" in any sense worth acting on.

It only ever points something out. Nothing is deleted, hidden or merged, and the message opens with one tap.

---

The AI summary

Off until you turn it on. When it is on, a short summary sits at the top of each ticket: where things stand, what was asked, what has been done, and who owes the next move.

It always shows when it was written, how much it read, and how many messages have arrived since. That last one matters more than it looks: a summary that quietly describes a ticket as it was five messages ago reads exactly like one that is current, which is worse than having no summary at all. When the conversation has moved on, the panel says so.

Every version is kept. Pressing Refresh writes a new one and never overwrites the old — a later reading really can be worse than an earlier one, and without a history that loss would be silent. History shows every version ever written for that ticket.

Refreshing it automatically

Set Refresh automatically after this many new messages and FreeITSM rewrites the summary once the conversation has moved that far ahead of it.

Two things stop this running away with your bill:

• It only ever happens when somebody opens the ticket. There is no background job, deliberately — a nightly sweep of your open queue would charge you for summaries of tickets nobody looked at.
• Two people opening the same ticket at once cannot cause two charges.

0 means never, and the Refresh button is then the only thing that spends anything.

What it will not do

It is told never to infer a cause, a fix or a resolution that nobody wrote down — a summary that invents a fix reads exactly like one that did not — and to say so plainly when something is unclear, rather than papering over it.

You can also stop it reading internal notes, if notes on your desk hold things that should not leave it. Either way the summary is staff-only and is never shown to a requester.

Read it for me

Off until you turn it on. A button on the ticket that reads the whole thing and briefs you: the short version, how it got here, what is unresolved, and what it would do next.

It is allowed to make suggestions, and is required to label them as suggestions — that last section always opens with "These are suggestions, not conclusions." It is also told to separate what the ticket says from what it is inferring, every time, because the thing that goes wrong here is somebody acting on a confident guess.

Once written, it is kept. Opening it again is instant and costs nothing; Read again writes a fresh one when you want it, and earlier briefings stay in History.

Setting up the AI

Both AI features share the Tickets AI provider, configured once at Tickets → Settings → Reply cleanup — the same one the reply cleanup and merge summary already use. One API key for the module.

⚠️ Choose the model with care. Some models think at length before they answer, which is slow and charged for. Measured on a real install, the same job took 54.7 seconds with thinking on and 6.9 seconds with it off — and the fast answer was the better one. System → AI thinking switches it off per feature, and it is off by default. See AI Providers.

If a summary does get cut off before it finishes, the panel says so rather than serving you half an answer as though it were whole.

Settings reference

Tickets → Settings → General

Setting	Default
Shorten long messages	on
Shorten after about N lines	12
Always show the newest message in full	on
Shorten quoted history	on
Remember which messages you opened	on
Fold older messages	on
Recent messages to keep open	6
Flag messages that arrived before	on
Keep an AI summary	off
Refresh it after N new messages	0 (never)
Messages a summary reads	60
Let it read internal notes	on
Offer "Read it for me"	off

Related pages

• Reading Long Tickets — Developer Guide
• Ticket AI Reading — Developer Guide
• AI Providers — provider, model, key, and the thinking switch
• Merging Tickets — the other way a thread gets long
• Tickets