-
Notifications
You must be signed in to change notification settings - Fork 15
Landing Page
How to choose which page people see when they open FreeITSM, and how an analyst can override that choice for themselves. The technical version is Landing page β Developer Guide.
Asked for in discussion #63 by Thomas (tjedelhauser). Shipped in f1673644.
Opening FreeITSM without being logged in always took you to the analyst login. On an installation where most people are end users rather than analysts, that is an odd front door: the first thing your staff see is a sign-in page built for the service desk, not the portal they actually came to use.
System β Branding β Landing page. Two options:
| Setting | Where "/" sends an unauthenticated visitor |
|---|---|
| Analyst login |
login.php β the original behaviour, and still the default |
| Self-service portal | self-service/login.php |
Nothing is ever out of reach. The two login pages link to each other, so an analyst arriving at the portal is one click from their own login and vice versa. Typing either address directly always works regardless of the setting.
The setting only affects people who are not signed in. If you already have a session, opening FreeITSM takes you to your module list exactly as before.
Making the portal the front door is right for your end users, but it would cost your analysts an extra click every day. So they can opt out.
Preferences β Start page. Three options:
- Use the site default β whatever the administrator chose. The option names it, so you can see what you are agreeing to.
- Analyst login
- Self-service portal
The choice belongs to the analyst, not to the browser. Set it once and it is reapplied every time you sign in, including the first time you sign in on a new computer. Clearing your cookies does not lose it either.
Why this one is slightly different from your other preferences. Everything else on the Preferences page is read after you have signed in. This one has to be read before you sign in, because it decides where sign-in happens. So as well as being saved to your account, it is stored in the browser you are using. That is what makes it work on the very first page you see, and the account copy is what makes it follow you to a new machine.
The self-service portal has no preferences area, so an end user gets whatever the administrator chose. That is the intended direction of travel: the setting exists so administrators can point end users at the portal, and analysts are the ones who need the escape hatch.
You run FreeITSM for a company of 200 staff, of whom 6 are analysts.
- System β Branding β Landing page β Self-service portal. Everybody who types your FreeITSM address now lands on the portal, which is what 194 of them want.
- Your 6 analysts each open Preferences β Start page β Analyst login. They are back to a single click, and nobody has lost anything.
- An analyst gets a new laptop. The first time they sign in on it, their choice is applied there too β nothing to set up again.
- A member of staff needs to reach the analyst login for some reason. The link is on the portal login page.
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)