Skip to content

Issue 79 Ticket Source Not Set

Ed Mozley edited this page Aug 19, 2026 · 1 revision

A ticket from email did not say it came from email (issue #79)

Tickets created by collecting mail had an empty Source. Nothing recorded that they had arrived by email, so no report could tell email tickets from any other kind.

Reported in issue #79 by tjedelhauser.

Fixed in 2f31fca7 and c7a832ec, released as update #1112.

The same report also covered the empty Status field, which has a different cause β€” see A new ticket arrived with no status.


1. What you saw

Nothing dramatic. The ticket was complete and correct in every other respect; the Source field was simply blank, on every ticket that had ever arrived by email.

Unlike the status half of this report, this one reproduced everywhere. It had nothing to do with language or renaming β€” the mail collector had never set an origin at all.


2. The mechanism

There is no mechanism to explain, which is the point. The column was not in the statement:

INSERT INTO tickets (
    ticket_number, subject, status_id, priority_id,
    created_datetime, updated_datetime, user_id, tenant_id
) VALUES ( … )

No origin_id. The mail path had never written one.

Other intake routes did β€” web chat and the messaging channels both call getChannelOriginId() β€” but nothing equivalent existed for mail.


3. Why it could not be fixed in one line

The obvious fix is to look up the origin named Email and use it. That is exactly the fault described in the other half of this report, and ticket_origins is worse placed to survive it than the status table:

ticket_statuses ticket_origins
A flag marking the "normal" row is_default βœ… none ❌
Names editable by the administrator yes yes
Scoped per company no yes β€” tenant_id

So there was no reliable way to ask "which row means email?". Matching the name walks straight back into the reported bug; and on a multi-company installation there can legitimately be several origins with similar names belonging to different companies.

The better question

The maintainer's answer reframed it, and produced a better feature than the one being asked for:

"In Tickets β†’ Settings β†’ Mailboxes there could be a little dropdown that says default ticket origin for this mailbox. I think it should be a per mailbox setting because you might want one mailbox to be 'User email' as the origin but maybe another mailbox could have an origin of 'Solarwinds Monitoring'."

That dissolves the problem rather than solving it. You pick the origin from a dropdown, so it is stored as an ID and there is no name to rename. And it is more accurate than one global answer could ever be: a helpdesk address and a monitoring address both arrive as email, and marking an automated alert as though somebody had written in is only true in the narrowest sense.


4. The fix

Each mailbox carries its own Default ticket origin, chosen under Tickets β†’ Settings β†’ Mailboxes, stored as target_mailboxes.default_origin_id.

When mail opens a ticket, that origin is stamped on it. Replies joining an existing ticket change nothing β€” origin describes how a ticket started.

The multi-company rule

  • A mailbox pinned to a company may use that company's own origins as well as the global ones.
  • A shared-intake mailbox may use only global origins, because its tickets land in whichever company the sender's domain matches, and one client's private label has no business on another client's ticket.

Global origins always exist, so no mailbox is ever left unable to record an origin. The rule is enforced on the server, not merely filtered in the dropdown.


5. The part that was not asked for

The fault was invisible for a long time, and the reason is worth more than the fix: the mailbox was authenticated, green and collecting mail perfectly. Nothing was broken enough to error. The only symptom appeared weeks later, on the tickets.

So every mailbox now carries an ! beside its name, listing what is quietly wrong with it β€” each item saying what the consequence is rather than naming a setting:

Severity Examples
Error Reading the wrong inbox Β· credentials that no longer decrypt Β· the chosen origin has been deleted
Warning No ticket origin set Β· never signed in Β· not checked for mail in days Β· set to file imported mail into a folder that was never named Β· an IMAP mailbox with no outgoing server

A mailbox with nothing wrong has no mark at all.

Warnings can be dismissed. Errors cannot.

The first version marked "not assigned to a company" as a problem, and the maintainer stopped it:

"this could be by design in which case the admin is stuck with a warning sign forever"

He was right, and it was four or five checks, not the one he spotted. A mailbox being inactive, a receive-only IMAP mailbox, a mailbox you genuinely want no origin recorded for β€” all deliberate, all nagging for ever.

  • Two checks were removed entirely β€” inactive and shared intake. Both already appear as a badge on the same row, so flagging them again was duplication as well as nagging.
  • Warnings can be dismissed. Dismissing says "I know": the mark clears, and the item stays listed inside with a Restore beside it. Acknowledging is not the same as hiding.
  • Errors cannot be dismissed. Reading the wrong inbox is a fault, not a preference, and it is the one case where letting somebody silence the warning would be worse than never having shown it.

The general lesson: a warning that fires on a deliberate configuration can never be cleared, and a mark that never clears is one people stop reading. It takes the useful marks down with it.


6. πŸ“ The files involved

πŸ—„οΈ schema Β· πŸ“– read Β· ✏️ write Β· πŸ–₯️ UI

🎨 File What it does
πŸ—„οΈ database/freeitsm.sql target_mailboxes.default_origin_id and health_dismissed
πŸ—„οΈ includes/db_verify_schema.php The same two columns, so Verify creates them on upgrade
✏️ api/tickets/check_mailbox_email.php Reads the mailbox's origin and stamps it on the new ticket
✏️ api/tickets/save_mailbox.php Validates the chosen origin against the mailbox's company
πŸ“– api/tickets/get_mailboxes.php Returns the origin and the computed problem list
πŸ“– includes/mailbox_health.php Every check, its severity, and whether it can be dismissed
✏️ api/tickets/set_mailbox_health_dismissed.php Acknowledge or restore one warning
πŸ–₯️ tickets/settings/index.php The dropdown, the ! and the problems dialog

7. How it was verified

Check Result
A shared-intake mailbox given another company's private origin Refused by the server
A company-pinned mailbox given that company's own origin Accepted
A shared-intake mailbox given a global origin Accepted
Ticket inserted the way the mail path now does Open / Normal / Email β€” both halves of #79 correct in one row
Dismissing a warning Mark clears; item stays listed with Restore
Restoring it Mark returns
Dismissing an error key Refused by the API, not just hidden in the UI
Dismissing a key that is not currently a problem Refused β€” otherwise a future genuine warning would arrive pre-silenced
A mailbox with nothing wrong No mark, and the dialog reads "Nothing to report"

The dropdown contents were read from the running page, not the source: a shared-intake mailbox was offered the global origins only, while a company-pinned one was additionally offered the company-private origin planted for the test.


8. What this means for you

  • Set a Default ticket origin on each mailbox. Until you do, its tickets record no source β€” and the ! on the row will say so.
  • Use it to tell your mailboxes apart. Email for the helpdesk address, something like Monitoring for an alerting one, and your reports can finally separate them.
  • Existing tickets are not backfilled. Nothing knows which mailbox an old ticket came through, and inventing an answer would be worse than the blank.
  • Check the ! on each mailbox once. It is the fastest audit of your mail setup available, and most of what it reports has been true for a while.

Related pages

FreeITSM

Getting Started

Modules

Multi-tenancy (planned)

Blue sky thinking

Bugs resolved

Links

Clone this wiki locally