Public Web Address

The public web address (and [ticket_url])

FreeITSM sends links to people who are not looking at FreeITSM: a confirmation email to a requester, a work item pushed into Jira, a webhook posted into Slack. Those links have to carry the site's full address, and this page is about the one setting that supplies it.

Set at Tickets → Settings → Email Templates, at the top of the screen.

---

1. Why a setting exists at all

Every link inside FreeITSM is a path — /tickets/?id=409 — and that is correct, because the browser already knows which site it is on. A link sent somewhere else has no such luck: the reader's mail client resolves it against nothing at all, or against their own webmail host, and it fails.

The obvious answer is to read the site's address off the current request. It works, right up until the moment it matters:

Most automatic email is sent when nobody is using FreeITSM. The mail collector runs on a schedule, notices a new message, opens a ticket and sends the acknowledgement — all with no browser involved. There is no request to read an address from, so a link built that way comes out with no site name in it.

That is why the configured address comes first and is not merely a fallback. Unattended is the normal case for outbound mail, not the exception.

---

2. What to type

The whole address people use to reach FreeITSM, including the folder if it is in one:

Your installation	What to enter
https://itsm.example.com/	https://itsm.example.com
https://example.com/freeitsm/	https://example.com/freeitsm
Reached over plain HTTP	http://… — type the scheme and it is kept

A bare itsm.example.com is accepted and assumed to be https://. A trailing slash, and anything after the host such as ?id=4 pasted from your address bar, is trimmed.

The folder is the part people leave off, and it is the part that breaks things: without it every link points at a page that does not exist on that host.

---

3. [ticket_url]

A merge code, usable anywhere the others are — in email templates and in canned responses:

Hi [requester_first_name],

Thanks — we've logged this as [ticket_reference] and someone will be in touch.

You can track it here: [ticket_url]

It resolves to the requester's own view of their ticket in the self-service portal. Somebody who is not signed in lands on the portal login page with the ticket remembered, so they arrive where they meant to.

It points at the portal rather than the analyst view on purpose: everything built from this data is addressed to the requester, and an analyst link would send them to a sign-in page they have no account for.

---

4. What happens if you do not set it

Nothing breaks while you are sitting there — a link built during a request picks the address up from the request, and looks perfectly correct. That is exactly what makes this worth warning about: the sample link an administrator sees while setting up is not the link that gets sent at three in the morning.

So the templates screen watches for the one combination that is genuinely wrong — a template that uses [ticket_url], on an installation where nothing has been configured — and says so:

Links in these emails will be broken. [ticket_url] is used in 2 template(s), but no public web address is set.

The message can be dismissed, because it is not always a fault: an installation whose templates are only ever sent by an analyst pressing something, on a single host with no reverse proxy, gets a working link from the request every time. A warning that cannot be silenced when it does not apply is one people stop reading, and it takes the ones that matter with it. Setting the address clears it for everyone regardless of what was dismissed.

The warning does not appear if the screen could not load the setting — an administrator who has configured this correctly should never be told they have not, and a failed request looks identical to an empty one unless you are careful to tell them apart.

---

5. What else uses it

The same address builds the link FreeITSM puts into a Jira issue or Azure DevOps work item when a ticket is escalated. That link is the entire reason for putting one there — somebody has to be able to click back.

This is where a long-standing fault was fixed. Web chat has always had its own address setting for webhook URLs, which stores the origin only (https://example.com) because the webhook builder adds the folder itself. The tracker links assumed the opposite shape and appended their path directly, so an installation in a folder produced https://example.com/tickets/?id=409 — the folder missing, the link dead. Both shapes are now reconciled in one place: the folder is added when it is not already there, and never twice.

Setting	Shape	Set at
Public web address	Whole root, folder included	Tickets → Settings → Email Templates
Messaging public base URL	Origin only	Tickets → Settings → Messaging

The general one wins where both are set. If you only ever configured the messaging one, it is still used and the folder is added for you, so nothing needs re-entering.

---

6. 📁 For developers

File	Role
includes/public_url.php	publicBaseUrl(), publicAbsoluteUrl(), publicBaseUrlSetting(). The one home — anything building an outbound link should call it
includes/template_email.php	buildTicketMergeData() — where [ticket_url] is produced
includes/reply_templates.php	The merge codes offered for canned responses
includes/integrations/integrations.php	integrationsAbsoluteUrl() — kept as a name, now delegates
api/tickets/get_public_base_url.php	Reads the setting, and separately reports whether anything is configured

publicBaseUrlSetting() and publicBaseUrl() answer different questions and the difference is load-bearing: the second always returns something, which is what makes it safe to build a link with and useless for deciding whether to warn. Only the first can tell you nothing was configured.

includes/csat.php and includes/self_service_email.php still build their own addresses. They only ever run in request context, so they are not wrong today; folding them in is a separate job.

---

Related pages

• Limiting replies to particular senders — the other half of discussion #80
• Email signatures — request 3 from the same discussion
• Email Send Log — every email FreeITSM tries to send, and what happened to it
• Issue Trackers — the Jira and Azure DevOps links this same address builds
• Self-Service Portal — where [ticket_url] sends people