-
Notifications
You must be signed in to change notification settings - Fork 15
Issue 79 Ticket Source Not Set
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.
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.
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.
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 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.
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.
- 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.
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.
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.
ποΈ 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 |
| 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.
- 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.
- Bugs resolved β the index of write-ups like this one
- A new ticket arrived with no status β the other half of the same report
- Mailbox authentication β the mailbox settings this joins, and the health mark
- Never identify a lookup row by its name β why the origin is stored as an ID
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
- Architecture
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- Theming & Dark Mode
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
- MobileβFriendly
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ Basic IMAP mailboxes
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- Problem Management
- Tasks
- Assets
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
- Forms
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
- CMDB
- Network Mapper
- Workflows
- Issue trackers (Jira, Azure DevOps)
- System
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)