Portal Privacy

Portal privacy: what requesters see of their own ticket

Where: Tickets → Settings → Privacy Default: Hide them from the requester Affects: the self-service portal only. Nothing changes for analysts.

The problem in one sentence

A ticket is not only your conversation with the person who raised it — and until this setting existed, the portal showed them all of it.

When an analyst forwards a ticket to a supplier, or copies in a colleague, that message is filed on the same ticket. So is the supplier's reply. That's exactly what you want internally: one ticket, one complete history, nothing scattered across mailboxes.

But the self-service portal was showing the requester that entire history. So correspondence about them was visible to them:

"Hi Dave — sending this one over, the customer's being difficult about the renewal. Pricing sheet attached."

…appearing in the customer's own portal, with the pricing sheet downloadable.

The three options

Option	The message	Its attachments
Hide them from the requester (default)	Not shown at all	Not downloadable
Show the message, but not its attachments	Shown	Not downloadable
Show everything	Shown	Downloadable

Show everything is exactly how FreeITSM behaved before this setting existed. If your team relies on the requester seeing forwards — some desks deliberately work "in the open" with their customers — choose it after updating.

What the setting does not touch

Three things are decided elsewhere and are unaffected by whichever option you pick:

• Internal notes are never shown in the portal. They never were. That's what the Internal flag on a note is for, and it remains the right place for anything you don't want the customer reading.
• The requester's own messages are always shown. Anything they sent you, and any reply addressed to them.
• WhatsApp and web chat conversations are always shown in full. Those exchanges are between the requester and your desk by definition — there is no "forward" on those channels, so there is nothing to hide. (See How the rule works for why this needs stating explicitly.)

How the rule works

Here is the part worth understanding, because it explains the edge cases.

FreeITSM does not record that a message was a forward. A forward and an ordinary reply are stored identically — same table, same columns, same everything. Adding a "this was a forward" marker would only work for mail sent after the update, leaving every forward already in your system visible forever.

So instead of asking "was this a forward?", FreeITSM asks the question that actually matters:

Was this message to, or from, the person who raised the ticket?

If yes, it's their correspondence and they see it. If no, it's third-party and the setting decides.

That single question is better than a forward flag in three ways: it catches CCs to colleagues as well as forwards, it catches the supplier's reply coming back in, and it works on every ticket you already have with no migration.

When FreeITSM can't tell

Some messages can't be judged by that question, and every one of them is shown:

Situation	Why it's shown
WhatsApp / web chat	Addressed by phone number or visitor id — the requester's email matches nothing, so an address check would hide their whole conversation from their own portal
A message with no recipient recorded	Nothing to compare against
A requester with no email address on file	Nothing to compare against

This is deliberate, and it's the one place the design leans away from privacy on purpose:

Hiding an analyst's genuine reply is worse than showing a forward. A customer who can't see the answer concludes nobody helped them, opens a second ticket, and phones you. Ambiguity therefore resolves to visible, and the strict direction is something an admin chooses per option — never something FreeITSM guesses at.

Worked examples

Assume Sarah Chen (sarah.chen@northwind.co.uk) raised ticket ABC-123-45678 about a broken laptop, and your service desk mailbox is support@yourcompany.com.

Example 1 — an ordinary reply

An analyst replies to Sarah.

From	support@yourcompany.com
To	sarah.chen@northwind.co.uk

Sarah is a recipient → her correspondence → always visible, under all three options. Her attachments download normally.

Example 2 — forwarding to a supplier

The laptop is under warranty, so an analyst forwards the ticket to the vendor, attaching the diagnostic report.

From	support@yourcompany.com
To	warranty@laptopvendor.com

Sarah is neither sender nor recipient → third-party.

• Hide — Sarah sees nothing. Her thread jumps from the analyst's last reply to whatever comes next.
• Show without attachments — Sarah sees "we've raised this with the vendor" and the message body, but cannot download the diagnostic report.
• Show everything — Sarah sees the message and can download the report.

Example 3 — the vendor replies

The vendor answers, and their reply lands on the same ticket.

From	warranty@laptopvendor.com
To	support@yourcompany.com

Still neither to nor from Sarah → third-party, and handled exactly like Example 2. This is the case a "was it a forward?" rule would have missed entirely — the reply isn't a forward, it's an ordinary inbound email.

Example 4 — a colleague copied in

An analyst replies to Sarah and CCs a network engineer.

From	support@yourcompany.com
To	sarah.chen@northwind.co.uk
Cc	ravi@yourcompany.com

Sarah is a recipient → visible. Being copied to someone else doesn't make it private from her — she's still being written to. The setting is about correspondence that isn't hers, not about who else is on it.

Example 5 — Sarah messages you on WhatsApp instead

Sarah's ticket came in over WhatsApp, addressed by her phone number.

Always visible in full. Her email address doesn't appear anywhere on those messages, so a strict address check would have hidden her own conversation from her. Chat channels are exempt for exactly this reason.

Example 6 — Sarah replies in the portal

Always visible. She wrote it.

An important detail about attachments

The setting is enforced twice — once when building the conversation, and again when a file is actually requested.

That matters more than it sounds. Attachments are fetched by a numeric id in the URL, and those ids are sequential and easy to guess:

/api/self-service/get_attachment.php?id=39

Simply leaving the link out of the page would be decoration, not protection — anyone could type the URL. So the download endpoint applies the same rule independently and returns a plain 404 when it doesn't pass.

Two related guarantees, both verified:

• You can only ever reach attachments on your own tickets. The check walks attachment → message → ticket and requires you to be the person who raised it. A wrong id and someone else's id both return the same bare 404, so the portal never even confirms that another customer's file exists.
• The portal is never told who else was on an email. The sender and recipient fields are used to make the decision server-side and then removed from the response.

Choosing an option

If your desk…	Choose
Treats forwarding to suppliers as internal business (most desks)	Hide them
Wants customers to see that work is happening, without exposing what was sent	Show the message, not attachments
Works transparently with customers and relies on them seeing the full trail	Show everything

If you're unsure, keep the default. It matches what most people assume is happening, and it's the only option where forwarding a ticket can't surprise you.

Under the hood

File	Role
includes/portal_visibility.php	The rule, the policy reader, and the three constants. One place, so the listing and the download can't disagree
api/self-service/get_ticket_detail.php	Filters the conversation; strips the routing fields from the response
api/self-service/get_attachment.php	Enforces the same rule on download, independently
tickets/settings/index.php	The Privacy tab UI
tickets/settings/manifest.php	Declares the tab, its capability and its setting key
includes/capabilities.php	Cap::TICKETS_PRIVACY

Stored as the portal_third_party_visibility system setting (hide / no_attachments / show). Absent means hide, so a fresh or upgrading install is protected before anyone finds the screen. No database change is needed for this feature.

See also

• Self-Service Portal — the portal itself
• Tickets — forwarding, replies and internal notes
• Admin Access Control — the capability that controls who can change this